Reverse Engineering der NLT II

[llm]

Es liegt am Zusammenspiel zwischen Entwicklern, Compiler, Betriebssystem, Source-Code und definierten Zielen.
Am Source-Code kann man jedoch was ändern, ...

bei der geringen Menge an Library/OS dependencies von BrightEyes oder gen werden Fehler wohl vornehmlich aus dem Source kommen, die verwendeten Libs sind schon sehr Battle-Proofed auf den enstprechenden Platformen - SDL2 ist da wirklich eine gute Wahl

Die Compileroptimierungen von MSVC/Delphi sind vergleichsweise mager im Vergleich zu GCC/Clang, welche wiederum mager gegenüber dem ICC von Intel ist.

der ICC wird seit Jahren immer schwächer gegenüber Clang - aber der Mythos "der Intel" macht den besten Code hält sich hartnäckig  - im Grund haben viele Entwickler kaum Ahnung davon was "Performant" bedeutet oder wie man da hin kommt - auch ein Grund für die Entwicklung von Clang-CL - Microsoft Frontend/Clang Backend, volle integration ins VStudio weil der sich eben wie der Microsoft CL verhält, nebst PDB(Debug Symbole) Erzeugung für den VStudio Debugger und mischbarer Builds mit CL und Clang-CL für Libs/Dlls/Exen

Und genau das ist eines meiner Anliegen mit BrightEyes, solche unentdeckten Fehler zu entfernen, da unter DOS z.B. kein Speicherschutz vorhanden war,
die Compilermeldungen besser geworden sind und heute mehr Platz auf dem Bildschirm ist.

hast du mal an einen Coverity-Einsatz gedacht - für Open-Source Github Projekte ist das ja kostenfrei und Coverity ist schon sehr mächtig - auch wenn die anderen statischen Analyser da draussen (PVS-Studio, Clang-Tidy, CppCheck etc.) auch keine schlechte Arbeit machen - aber Coverity ist schon noch mal stärker - aber eben super teuer für kommerzielle Entwicklung (ein Kunden von mir hat das im Einsatz und da wird a' 100.000 Zeilen oder so gezahlt - war mal was mit 15-20TEUR im Jahr)

hier anmelden: https://scan.coverity.com/github

Richtig: Aus Fehlern wird man klug, deshalb ist einer nicht genug!

meine Erfahrung ist - je mehr unterschiedliche Betriebssystem und Kompiler drauf geworfen werden um so mehr findet man
Bei einem meiner Kunden bauen wir von alt gcc/clang/msvc bis neu und alt Linux/Windows/FreeBSD bis neu, x86/x64/ARM32/64(/früher sogar noch Sparc) alles automatisch durch mit Tests, das alles mit ASAN/TSAN und statischer Analyse - das ergibt schon ein sehr sicheres Gefühl - obwohl klar ist das es immer noch Fehler gibt - oder neue rein kommen