nicht angemeldet
Können wir nicht einfach alles zum Thema punkt 4) bei dem belassen.
Nein.
Jeder denkt sich seinen Teil und wir blenden alles dem bezüglich bis zur Problemlösung aus?
Du möchtest offenbar gerne, dass Dein Code Anklang findet.
Sorry, aber dazu ist der Code aber einfach nicht gut genug:
Fest "eingebrannte" globale Pfade in den Tiefen irgendeiner Funktion sind eben kein guter Stil; genauso wenig wie "ausgerollte" Schleifen.
Wenn Du solchen Code vorlegst kannst Du nicht erwarten, dass andere Programmierer mit Dir auf Augenhöhe technisch diskutieren.
Differenzen wird es immer geben. Aber es muss doch möglich sein sowas kurz zu vergessen und sich auf das wesentliche zu konzentrieren.
Nicht Differenzen sind Dein Problem sondern Deine Einstellung.
In Deinem Code sind keine Mechanismen zur Vermeidung von häufigen Speicherlecks und Bereichsüberschreitungen zu finden; std::vector<T>, std::map<T> und dergleichen sind aber genau dafür gedacht.
Wenn Du an Stellen die nach Containern "schreien" solche nicht verwendest setzt Du sie auch nicht in kritischen Codeteilen ein; erzähl mir bitte nicht, der Rest Deines Codes sähe besser aus.
Es erfordert zugegebenermassen einigen Aufwand, sich in die STL einzuarbeiten.
Aber zumindest ein (C) Array mit const char* und einem (const char*) NULL als Terminator sollte drin sein.
Ich gebe dir ja recht. Der Code ist so nicht schön.
Der ganze Code ist an mehreren stellen nicht schön. Aber man wird auch in schon als perfekt abgehakten Code noch was zu bemängeln finden.
Wenn der Code nicht funktioniert?
Auf jeden Fall!
Also ich wäre dafür das man trotz diesem Punkt 4) und allem was danach bezüglich Punkt 4) gefolgt ist, sich auf mein wirkliches Problem beschränkt.
Deine Probleme sind folgende:
- Du scheust Dich offenbar davor mit dem Debugger systematisch zu arbeiten:
Und wenn ich was finde, das ist alles SDL intern, da müsste ich ja in der SDL den Fehler ausmerzen. Aber das will ich nicht.
Damit stehst Du nicht allein; viele Programmierer, die von Skript-Sprachen zu C/C++ gekommen sind, zeigen dies Verhalten; meist sind fehlende Grundkenntnisse in Assembler das Hauptproblem.
Aber C und C++ sind keine Skript-Sprachen.
Es nützt aber nichts jahrelang die Sinnlosigkeit von Debug-Sitzungen zu betonen statt sich einmal zu erarbeiten was EAX, ESP... denn wohl bedeuten.
- Du verwirfst Lösungsansätze ohne sie auszuprobieren:
Dass Du selbst keine eigenen Threads erzeugst ist kein hinreichendes Kriterium; wie hast Du z.B. ermittelt, dass die Bibliotheken keine eigenen Threads erzeugen; etwa für die Oberfläche?
Das kann ich mir sehr schwer vorstellen.
Es ist unerheblich ob wir uns etwas vorstellen können. Test und Analyse schaffen Gewissheit.
Auf diese Hypothese
atexit(irgendwas);
/*und
später */
irgendwas();
riecht nach nach einem free() auf einen nicht genullten Zeiger auf dem »» »» schon mal free() aufgerufen wurde.
bist Du bislang auch nicht eingegangen.
Warum eigentlich nicht?
Was spricht gegen ein "//" vor dem atexit() und ein paar Testläufe?
Sollte ich die falsche Wortwahl getroffen haben, möchte ich mich dafür entschuldigen.
Die Entschuldigung ist angenommen, aber das heißt noch nicht, dass wir weitermachen.
Wenn Du bei jeder Kritik an Deinem Code derart defensiv reagierst kommen wir nicht weiter.
---
Solche Debatten sind im Bereich C/C++ nicht selten; die kenne ich seit meinem ersten Projekt (und das ist schon etwas länger her):
"Nein, Debuggen brächte nichts!"
"Die STL brächte nichts, die kostet nur Performance und ist buggy!"
"Mein Code funktioniert zwar grad nicht, ist aber ansonsten SUPER!"
[...]
So wurde aber noch nie ein Problem gelöst, mittels "Code aufräumen" und Debuggen hingegen schon!
Einen Hoffnungsschimmer sehe ich aber bei Dir:
Ich gehe stupide davon aus das alle Fremd-Libs absolut Fehlerfrei sind. Der Fehler befindet sich immer beim User also bei mir im Programm.
Das ist generell eine gute Einstellung!
Allerdings ist es in diesem konkreten Fall durchaus möglich, dass in OpenSource-Bibliotheken, die irgendwann mal von 32 auf 64 Bit migriert wurden irgendwo noch ein Fehler steckt und sei es nur im Zusammenwirken mit X, dem konkreten Treiber und Kernel usw.
---
Jetzt müsstest Du Dir mal überlegen, wie Du mit dem Problem weiter umgehen willst.
Grüsse
Solkar
Benedikt