Klotzkopp

Auf 7 kommt man, wenn man zuerst den rechten Operanden des + auswertet, und dann erst den linken.

Das Ergebnis dieses Ausdrucks ist in C und C++ nicht definiert. Der Compiler darf da tun, was er will.

Schau dir doch mal genau aus, was in dieser Schleife passiert. In der Schleife werden l und r aufeinander zu bewegt. Die Art und Weise, wie das passiert (und wie sich der Abstand der beiden dabei entwickelt), ist der springende Punkt.

Hallo und Willkommen auf dem Board Beispielprogramme solltest du eigentlich massenweise im Internet finden können, und ich glaube kaum, dass sich jemand die Mühe macht, hier für dich ein persönliches Tutorial zu verfassen. Der Umgang mit List Controls ist in C# nicht grundsätzlich anders als in C++. Stell doch bitte konkrete Fragen. Mit Problembeschreibungen wie "ist aber sehr schnell in einer Sackgasse geendet" und "will immer noch nicht funktionieren" kann niemand etwas anfangen.

Das ist keine besonders gute Problembeschreibung. Mir fällt auf jeden Fall auf, dass du die Ergebnisse nicht einfach so "by value" übergeben darfst, weil sich Änderungen an diesen Parametern nicht auf die Variablen auswirken, mit denen du die Funktionen aufgerufen hast. Das sollten also schon Referenzen sein.

Das ist keine besonders gute Problembeschreibung. Mir fällt auf jeden Fall auf, dass du die Ergebnisse nicht einfach so "by value" übergeben darfst, weil sich Änderungen an diesen Parametern nicht auf die Variablen auswirken, mit denen du die Funktionen aufgerufen hast. Das sollten also schon Referenzen sein.

atoi ist C. Deklariert wird die Funktion in <stdlib.h>. Wenn das bei dir nicht funktioniert, machst du etwas falsch. Was du falsch machst, kann man wegen der unzureichenden Fehlerbeschreibung ("hat leider versagt") nicht feststellen. Das Problem ist, dass du - obwohl du bereits auf diesen Fehler hingewiesen wurdest - immer noch ungültige Indizes beim Zugriff auf die Arrays c und tmp benutzt. Nochmal ganz deutlich: Der erlaubte Index für tmp geht von 0 bis 2. Der einzige erlaubte Index für c ist 0. Du darfst nicht auf c[1] zugreifen. Du darfst nicht auf tmp[3] zugreifen. Was du da machst, erzeugt undefiniertes Verhalten, da kann alles passieren. Hier ist es vermutlich so, dass du dir mit den ungültigen Zugriffen die Werte der übrigen Variablen zerlegst.

Ein break hilft nur bei einfachen Schleifen, nicht bei mehreren verschachtelten. Will man da aus einer der inneren Schleifen herausspringen, muss man etwas anderes benutzen, z.B. eine bool-Variable, die in jeder Schleifenbedingung zusätzlich geprüft wird. Man kann auch das gesamte Schleifenkonstrukt in eine eigene Funktion auslagern, und dann mit einer return-Anweisung vorzeitig rausspringen. Exceptions würde ich in so einem Fall auch nur mit Vorsicht einsetzen. Exceptions sagen für mich im Code etwas besonderes aus, nämlich dass eine Ausnahmesituation behandelt wird, etwas, das im normalen Programmablauf nicht vorhersehbar ist. Eine Exception für einen zwar vorzeitigen, aber dennoch erwarteten Abbruch zu verwenden, halte ich deshalb für fragwürdig. IMHO ist es nicht sinnvoll, irgendein Sprachmittel grundsätzlich abzulehnen. Wer goto ohne Kenntnis der Situation verteufelt, sollte IMHO auch gleich von break, continue und vorzeitigem return die Finger lassen, denn letztendlich ist das dasselbe: Ein unbedingter Sprung.

Das ist richtig so. Wenn du einen Zeiger mit dem Arraysubskript-Operator verknüpfst, ist das Ergebnis kein Zeiger, sondern das Objekt an der betreffenden Stelle. Darum brauchst du für den Memberzugriff den Punkt, nicht den Pfeil. Die Zählung der Indizes beginnt übrigens bei 0, nicht bei 1. Bei einem CRanger[3] lauten die gültigen Indizes also 0, 1 und 2 (nicht 1, 2 und 3).

Sicher, das geht, ist aber stilistisch äußerst fragwürdig. Es mag Fälle geben, in denen goto angebracht ist, weil es den Code vereinfacht, aber hier würde ich das auf keinen Fall machen. Es ist auch gar nicht notwendig. Hier ist schon eine funktionierende Schleife. Hier wurde nur vergessen, die Variable counter zurückzusetzen.

Wie lautet denn die Fehlermeldung?

Ich bezweifile, dass du das Problem gelöst hast. Es tritt nur nicht mehr (oder nicht mehr so häufig) auf. Man könnte sagen, du hast es schwieriger reproduzierbar gemacht. Threadsynchonisierung mittels Warten ist keine saubere Lösung.

Greift dein "Prüfthread" etwa direkt auf die Fensterobjekte zu? Das ist nicht erlaubt. Nur der Thread, der ein Fenster erzeugt hat, darf darauf zugreifen. Das ist vermutlich ein Lesezugriff über einen Nullzeiger. Das ist ein sehr allgemeiner Programmfehler, und hat mit der Art des Programms wenig zu tun. Das liegt wahrscheinlich auch daran, dass du in deinem Thread Sachen machst, die du nicht machen darfst. Ich hatte dir gleich zu einem Timer geraten, da hättest du solche Probleme nicht.

RTF ist ein textbasiertes Dateiformat, du kannst also einfach mit den ganz normalen Filestreams eine Textdatei mit der Erweiterung .rtf erzeugen und da rein schreiben. Die aktuelle Dokumentation des Formats findest du hier: Download details: Word 2007: Rich Text Format (RTF) Specification, version 1.9 Wenn du die Daten nicht "von Hand" schreiben willst, musst du schon ein wenig mehr über dein Betriebssystem bzw. deine Entwicklungsumgebung verraten. Unter Windows beispielsweise könntest du auch ein Rich Edit Control über dessen API befüllen, und den Inhalt hinterher als Stream herausholen.

Wo hast du denn gesucht? LoadImage Function () Da steht: hinst ... To load a stand-alone resource (icon, cursor, or bitmap file)—for example, c:\myimage.bmp—set this parameter to NULL.

Du solltest hInst schon noch initialisieren. Da steht nicht automatisch der richtige Wert drin.

Die Version mit den 2 Parametern ist CWnd::AnimateWindow. Das Fenster wird da über den this-Zeiger des benutzten Objekts bestimmt. Diese Methode verdeckt die globale AnimateWindow-Funktion, weil dieser Code in einer Methode einer von CWnd abgeleiteten Klasse steht. Wenn du auf die globale Funktion zugreifen willst, setz einfach zwei Doppelpunkte vor den Namen: ::AnimateWindow(hWnd2, 1000, AW_BLEND);

Warum sagst du es denn nicht einfach? Ist der Code nicht von dir? Der Compiler weiß nicht, was du mit dem Code meinst. Wir wissen es auch nicht. Wir können natürlich irgendeine Lösung vorschlagen, die die Unklarheiten für den Compiler ausräumt. Ob der Code dann aber das tut, was du willst, ist Glückssache. Willst du prüfen, ob der String leer ist? Willst du prüfen, ob das erste Zeichen ein Nullzeichen ist? Oder etwas ganz anderes?

Den Code lesen kann ich selbst. Was soll dieser Vergleich bewirken? Was glaubst du, was der Vergleich mit NULL tut? Das ist doch der springende Punkt.

Was soll der Code denn überhaupt bewirken?

Das ist allerdings nicht das, was man normalerweise Syntax nennt. Kannst du etwas genauer erklären, was du suchst?

Wieso nicht? X kann ja auch 1 sein. Nein. Ein Timer reicht völlig aus. Du kannst den Timer ggf. auch flexibel halten, d.h. wenn der nächste Alarmzeitpunkt weit entfernt ist, das Timerintervall raufsetzen.

Ich würde sagen, für diese konkrete Aufgabe reicht stumpfes Ausprobieren. Brute Force, sozusagen. Auch Eulers Satz findet nicht alle Paare. Paar Nummer 2 und 7 wurden nicht von Euler, sondern erst viel später gefunden: Vollkommen, befreundet, gesellig Wie ich schon zu Anfang sagte: Diese Sätze helfen dir bei der Lösung dieser Aufgabe nicht.

Das hast du falsch verstanden. Der Satz findet für n=2 das Paar (220, 284), für n=3 nichts, und n=4 das Paar (17296, 18416). Dazwischen fehlen schon 6 Paare. Das nächste Paar findet der Satz für n=7 (9.363.584, 9.437.056), das ist schon weit jenseits der Aufgabe. Und danach findet der Satz erst wieder frühestens für n=191600 etwas. Gesucht ist das hier: 220 284 1184 1210 2620 2924 5020 5564 6232 6368 10744 10856 12285 14595 17296 18416 63020 76084 66928 66992 67095 71145 69615 87633 79750 88730 Davon findet man mit Thabits Satz gerade mal 2 Paare.

Die Sätze von Thabit/Euler/Borho liefern nicht alle befreundeten Zahlen. Die Anwendung dieser Sätze löst nicht diese Aufgabe. kaniuygun, darfst du Funktionen benutzen? Und ist es sicher, dass es C++ sein soll? Dein Code sieht stark nach C aus.