Klotzkopp

Hast du im Zuge dieser Umstellung irgendwo Managed Code hinzugefügt? Oder das Projekt auf die Verwendung der Common Language Runtime umgestellt? Solange du die MFC-Bibliotheken nicht selbst baust, ist das egal. Aber bist du sicher, dass du auf VS7 umgestellt hast, und nicht auf VS8 (2005)? VS7 sollte eigentlich auch eine occcont.cpp enthalten, aber davon ist bei dir keine Spur.

Werden noch weitere Trace-Ausgaben erzeugt? Die müssten im Output des Debuggers erscheinen.

Das heißt, das lief schon mal? Dann die Standardfrage: Was hast du gemacht? Das ist der interessante Teil. Such bitte diese Datei auf deinem Rechner, und schau nach, was da in Zeile 926 passiert. Welche Funktion ist das? Der Pfad in der Assertion bezieht sich übrigens nicht auf deinen Rechner, sondern den, wo deine MFC gebaut wurde (also irgendwo bei Microsoft). Die Datei sollte aber trotzdem auf deinem Rechner sein, irgendwo im VC-Installationsverzeichnis. Nachtrag: Die Datei heißt occcont.cpp (also drei c). Bevor du vergeblich nach dem falschen Dateinamen suchst

Was für ein Steuerelement ist das? Wie hast du es eingefügt?

Die Schleife mit dem Vergleich ist doch schon im Programm drin. Du musst nur die Vergleichsbedingung und die Implementierung der change-Funktion ändern.

Was meinst du? Dass der f-Suffix ein Float-Literal kennzeichnet? Das steht so im Standard, genau wie l (L) für long double. Oder meinst du die Warnung selbst?

Dadurch kann der Speicher nicht vollaufen. Wenn dein Programm abstürzt oder du es schließt oder abschießt, gibt Windows den gesamten angeforderten Speicher wieder frei. Wenn die geschilderten Symbole - Windows wird langsam und die Festplatte arbeitet durchgehend - bei dir nicht auftreten (es wäre übrigens nett, wenn du das mal klarstellen würdest), dann ist das Speicherleck nicht dein primäres Problem.

Ja, da sind wir derselben Meinung. Die Frage ist, warum new 0 zurückgegeben hat. Eine Möglichkeit ist, dass der Speicher wirklich voll ist. Eine andere ist, dass Sloenig sich den Heap zerlegt hat. Ich zweifle nicht daran, dass da auch ein Speicherleck drin sein kann. Ich glaube nur nicht, dass es die Ursache des Absturzes ist. Wenn man Speicher in 2K-Blöcken anfragt, ohne sie wieder freizugeben, dann wirkt sich das nach meinen Erfahrungen eher so aus, dass Windows immer langsamer wird und schließlich nur noch mit Auslagern beschäftigt ist und damit praktisch stehenbleibt. Das ist aber anscheinend nicht der Fall. Um wirklich eine Out-of-memory-Situtation zu provozieren, muss man IMHO einen so großen Block anfordern, dass Windows vor der Allokation noch funktionsfähig war. 2 KByte-Häppchen reichen da nicht. Darum tippe ich auf den kaputten Heap.

Mir erschließt sich der Sinn zwar absolut nicht, aber na gut... Schreib dir eine Klasse, die sich die gewünschte Länge, die Zeichen (z.B. als String) und die Stellenwerte (z.B. als Vector<int>, wobei die Werte jeweils als Index auf den String zu verstehen sind) merkt. Dann brauchst du noch einen operator++ zum Hochzählen. Der geht die Stellen von hinten nach vorn durch und prüft, ob ein Übertrag vorliegt. Falls nein, wird die Stelle um 1 hochgezählt. Fall ja, wird die Stelle auf 0 gesetzt und es geht mit der nächsten Stelle weiter. Schließlich brauchst du noch einen operator<<, der das Ding in seinem aktuellen Status ausgeben kann. Aber das ist ja nur eine einfache Schleife.

Dann würde ich nicht weiter nach einem Leck suchen, sondern nach einer Stelle, wo du auf Speicher zugreifst, der dir nicht gehört. Typische Kandidaten sind hier Bereichsüberschreitungen bei Arrays.

Der Luftwiderstand mag den Wurf in Abhängigkeit von der Form und der Masse des Objekts verlangsamen. Dadurch ändert sich aber nicht der Ort der Landung (relativ zum bewegten System). Ein Luftballon braucht zwar länger, bis er wieder runterkommt, aber er landet trotzdem in deiner Hand. Die einzige bei diesem Maßstab nicht vernachlässigbare Störgröße ist Luftbewegung relativ zum bewegten Bezugssystem (sprich: Fahrtwind).

Solange die Luft sich mit dem Bezugssystem bewegt (z.B. im Flugzeug oder im Auto mit geschlossen Fenstern) -> keine Auswirkung auf den Landeort. Auch das hat keine Auswirkung auf den Landeort, außer der Gegenstand schwebt/steigt in Luft. Siehe oben. Solange die Dichte der Luft nicht höher wird als die Dichte des Gegenstands -> keine Auswirkung.

Mir ist nur ein weiterer Störfaktor bekannt: Die Corioliskraft, hauptsächlich verursacht durch die Erdrotation. Die ist aber bei den gegebenen Geschwindigkeiten und Wurfweiten vernachlässigbar. Solange nur der Fahrtwind außen vor bleibt, klappt das. Der Wind wäre auch IMHO der einzige Anhaltspunkt für das Bandexperiment. Hast du ein paar Beispiele für die "tausend Eigenschaften", oder war das nur so dahingesagt?

Das liegt aber ausschließlich am Luftwiderstand. Auf dem Mond beispielsweise würde das funktionieren.

Steigt denn der Speicherverbrauch deines Programms stetig an? Das kannst du z.B. mit dem Taskmanager kontrollieren. Wenn Windows der physische Speicher ausgeht, dann wird die Auslagerungsdatei benutzt. Wenn die auch voll ist, wird sie normalerweise automatisch vergrößert. Das sollte sich durch eine extreme Verlangsamung des Computers und andauernde Festplattenaktivität bemerkbar machen. Ist das bei dir der Fall? Wenn nicht, hast du vermutlich kein Memory Leak, sondern einen kaputten Heap.

Nein, tust du nicht. Wenn du in einem sich bewegenden Bezugssystem etwas senkrecht nach oben wirfst, hast du als Resultierende die Überlagerung der senkrechten Bewegung des Wurfs und der horizontalen des Bezugssystems. Klassische Newtonsche Mechanik. Wäre auch etwas gefährlich, wenn du im Flugzeug einen Ball fallen lässt, und der bohrt sich dann mit mehreren hundert Kilometern pro Stunde in dich rein Die Sonne (und damit auch die Erde) bewegt sich übrigens mit über 200 Kilometern pro Sekunde um das Zentrum der Milchstraße (auch wenn das nur im relativistischen Sinne eine gleichförmige Bewegung ist). Es wäre schlecht, wenn sich das so auswirken würde, wie du es beschreibst.

Nein, er landet wieder in deiner Hand (wenn das Auto seine Geschwindigkeit nicht ändert, und der Ball nicht durch Fahrtwind o.ä. abgelenkt wird). Die Hand hat sich natürlich inzwischen weiterbewegt.

Das funktioniert nicht. Wenn du auf einem sich bewegenden Band etwas senkrecht nach oben wirfst, behält es die horizontale Geschwindigkeit des Bandes bei. Wenn du im fahrenden Auto einen Ball senkrecht nach oben wirfst, fliegt er dir ja auch nicht ins Gesicht, sondern landet wieder in deiner Hand.

:confused: Klar geht das. Nur um ganz sicher zu gehen: Auch in der app.pro steht HEADERS += src/TableWidget.h ?

In der Fehlermeldung auch? Hast du die wirklich nach dem Copy&Paste auf .cpp geändert?

Man braucht gar keine Funktionen. Man kann direkt mit dem Arrayoperator [] auf die Elemente zugreifen.

Offenbar hält Qt deine TableWidget.cpp für eine Headerdatei. Das ist schon mal merkwürdig. Warum hat die Datei eigentlich Include-Guards (#ifndef/#define/#endif)? Die braucht man nur bei Headerdateien. Du bindest doch hoffentlich nicht .cpp-Dateien über Includedirektiven ein?

Soll dein Programm von 0 bis ffffffffffffffffffffffffffffffff zählen? Wozu? Ist dir klar, wie lange das dauert? Selbst wenn dein Programm eine Milliarde Zeilen pro Sekunden ausgeben würde, würdest du das Ende nicht erleben. Das Programm wäre noch nicht mal zu 0.0000000001% durchgelaufen, wenn unserer Sonne der Brennstoff ausgeht. Wenn du das wirklich brauchst (was ich bezweifle; das sieht mir gerade eher nach einer Spielerei aus), dann solltest du dich nach einer Bibliothek für große Zahlen umsehen, z.B. die GNU Multi-Precision Library. Denn du brauchst hier einen Datentyp, der 128 Bit fassen kann. Mir ist kein Compiler für heutige System bekannt, der solche Größen mit den eingebauten Datentypen unterstützt.

Was meinst du damit?