Klotzkopp

Gerade bei Kindern würde ich so einen Sprachgebrauch eher erwarten, wenn die noch nicht wissen, wie man sich benimmt. Aber das ist unerheblich. Du hast den Boardregeln zugestimmt, also halte dich bitte daran.

Die Lösung ist übrigens nicht, dass du den Filter umgehst, indem du die Worte gesperrt schreibst und dich entschuldigst, sondern dass du dir eine angemessene Ausdrucksweise zulegst.

Verschoben -> Windows Betriebssysteme.

Alternativ kann man a als int belassen, und das so schreiben: ergebnis += (1[B].0[/B] / (a) * (a+1) * (a+2)); Dadurch, dass nun einer der Operanden vom Typ double ist - nämlich das Literal 1.0 - wird hier eine Fließkommadivision ausgeführt. Da passt das Ergebnis dann auch rein. So ist die Formel übrigens noch falsch. Es bringt nichts, den gesamten Ausdruck in Klammern zu setzen, denn der += Operator hat sowieso eine sehr niedrige Priorität. Aber der Nenner muss geklammert werden - also der Ausdruck mit den Multiplikationen. So wie das jetzt da steht, wird erst 1 / a gerechnet, und dann das Ergebnis mit (a+1) bzw. (a+2) multipliziert, und das ist ja nicht Sinn der Sache

Ja, im Web gibt's leider manches, was falsch (oder zumindest unnötig) ist. Du findest bestimmt auch etliche Stellen, an denen das mit %d gemacht wird Ich könnte mir vorstellen, dass eine fehlertolerante printf-Implementierung das l einfach ignoriert. Laut Standard werden float-Funktionsargumente sowieso in double umgewandelt, wenn kein Prototyp vorliegt, oder (wie bei printf) eine Ellipse. Eine Unterscheidung ist also bei printf ohnehin Unsinn, denn dort kommen niemals floats an. Bei scanf ist das natürlich anders, es gibt keine automatische Konvertierung von float* in double*. Wie soll das denn hier passieren? Float wird in double umgewandelt, nicht umgekehrt.

Nö. :floet: %lf gibt's bei printf nicht. Bei scanf hättest du Recht.

Kann man machen, ist aber ungewöhnlich. Man muss dann auch beachten, dass im Falle eines continue dann eben nichts passiert. Das zweite Semikolon muss aber in die for-Anweisung rein. Man kann beides benutzen, muss dann nur eben den Wert entsprechend anpassen. 100 ist hier mit beidem falsch

Ja, das ist im Prinzip alles. Aber wir möchten absoluteranfänger dahin führen, dass er sich das selbst erarbeitet, und nicht einfach nur vorsagen, denn dann kann er das nächste Problem selbst lösen.

Für ein einfaches 1/x würde ich kein Unterprogramm erstellen. Und wenn du nicht a++ benutzt, sondern wirklich a+1 bzw. a+2, dann brauchst du auch nicht zu befürchten, dass du etwas überschreibst. Du kannst ruhig auf einen Rutsch 1 / ( a * (a+1) * (a+2) ) ausrechnen, und das aufsummieren.

:confused: So war's aber nicht gemeint. Tut mir leid, falls das so rüberkam.

Das ist schon gar nicht schlecht. Eine Gesetzmäßigkeit, die das Ganze noch weiter vereinfacht, ist dir aber offenbar noch nicht aufgefallen: b ist immer a+1, und c ist immer a+2. Du brauchst also weder b noch c.

Kennen reicht nicht, man muss auch mal genau lesen. Denn dort wird in der Schleife auf das SearchResult-Objekt zugegriffen, das bei dir "ergebnis" heißt. Du machst mit diesem Objekt gar nichts, sondern versuchst aus de irgendwelche Daten rauszuholen.

Das ist IMHO ein schlechtes Beispiel. Das ist nicht einmal ein Struktogramm. Was soll "Programm Fahrenheit" für eine Schleife sein? Oder "Beginn/Ende"? Und was ist "Ausgabebildschirm fixieren"? Kann es sein, dass das ziemlich alt ist? Es würde mich jedenfalls nicht wundern, wenn da auch irgendwo "Lochstreifen auswerfen" auftauchen würde Es muss ja nicht mal ein PAP oder Struktogramm sein. Es reicht auch, das ganze einfach als Text zu formulieren, in etwa so: Eine Variable S für die Summe anlegen, mit Startwert 0 Eine Variable n von 2 bis 198 laufen lassen ... usw.

Nein, das ist überhaupt kein PAP. Das ist eine Wiederholung der Aufgabenstellung. Der Algorithmus formuliert die Lösung der Aufgabe. Begriffe wie "gewisse Regelmäßigkeit", "gewisser Maximalwert" und "Bruch" haben darin nichts zu suchen, denn damit kann ein Computer nichts anfangen. Auch welcher Art die Kontrollstrukturen sein sollen, ist hier nicht direkt relevant. Alle Arten von Schleifen lassen sich ineinander überführen.

Was für eine Ausbildung machst du denn da? Was ich meine: Du sollst zuerst den Algorithmus (also die Vorgehensweise zur Problemlösung) allgemein formulieren, unabhängig von einer konkreten Programmiersprache. Meinetwegen auch einfach als Fließtext in Deutsch. Erst dann sollst du diesen Algorithmus in die Programmiersprache C umsetzen. Wenn du nämlich beides gleichzeitig versuchst, kommt dabei nur Murks raus.

Lass doch erst mal den Code liegen, und formuliere einen Algorithmus, als PAP oder Struktogramm. Wenn das steht, kannst du anfangen, das in Code umzusetzen. Beides gleichzeitig klappt nur bei einfachen Problemstellungen, oder wenn du die entsprechende Erfahrung hast.

Wäre super, wenn du erst einmal erklären würdest, wie sich der "Fehler" äußert. Einfach nur einen Batzen Code hinzuklatschen, ohne jede Fehlerbeschreibung, ist ein wenig unhöflich.

Hat einer der "10 Parameter" ein Standardargument (Defaultwert)? Falls ja, muss der neue auch eins bekommen. Sobald du einem Parameter ein Standardargument verpasst, müssen alle nachfolgenden auch eins bekommen.

Versuch das bitte mal: typedef bool (__stdcall *pIpsEncrypt )( char *, char *, int ); [/code]

Aber nur, wenn man jeden Tag neu kompiliert.

Das ist das Problem. Das gibt's nicht. Mal ganz nebenbei: Ist dir klar, dass __DATE__ das Datum ist, an dem diese Datei kompiliert wurde?

Ich wage zu bezweifeln, dass du eine ofstream-Variable namens cout anlegen kannst. Eine Variable dieses Namens gibt es nämlich schon. Wenn du eine bessere Fehlerbeschreibung als "naja..." lieferst, sicher. Ach ja, falsches Forum. Verschoben -> C++: Compiler, IDEs, APIs

Wie lautet denn eigentlich deine Frage? Das, was du da "Autograph" nennst, kenne ich als Quine.

scanf("%f, &k"); // falsch scanf("%f", &k); // richtig[/CODE] Und für's nächste Mal: "es kommt eine Fehlermeldung" ist keine ausreichende Fehlerbeschreibung. Auch wenn dir die Meldung nichts sagt, uns kann sie für die Fehlerdiagnose sehr wichtig sein.

C ist recht nachsichtig, was fehlende Funktionsdeklarationen angeht, zumindest in der "alten" Standardversion von 1989.