Eigentlich kann ich fat-lobyte auch nur bestätigen
Glocke hat geschrieben:Hi, ich programmiere seit Jahren ohne IDEs, d.h. nur mit Texteditor und Terminal (in meinem Fall gedit und gnome-terminal unter Linux Ubuntu).
Zusätzlich arbeite ich mit GDB (als GUI "nemiver"). Nur hilft der mir oftmals nicht weiter. Anstatt er mir (mit Nemiver kann ich mir ja den Quellcode ansehen und Haltepunkte setzen) die Stelle liefert (an der die Speicherzugriffsverletzung auftaucht), zeigt er mir nur Assembler-Code (oder etwas derartiges - da bin ich nicht ganz auf der Höhe - sieht in jedem Fall sehr maschinen nah aus) an. Zum Debuggen hilft mir das nicht
Für gdb muss der GCC, wie fat-lobyte schon richtig sagt, mit der Option -g kompiliert werden. Dann ist das bei mir eben auch das Tool der Wahl, um derartige Fehler zu finden.
Valgrind emuliert quasi die komplette Maschine und registriert jeden(!) Speicherzugriff, ob der in einem gültigen Bereich stattgefunden hat. Das kostet viel Zeit, liefert aber eben auch viele wertvolle Informationen.
Und obwohl mich fat-lobytes Tipp mit Visual Studio erstaunt, ich kann Dir nur den selben geben. Zum einen ist es nicht verkehrt mehr als einen Compiler zum Kompilieren zu verwenden. Die Compiler entdecken unterschiedliche Fehler oder "Mängel". Und ich benutze Visual Studio auch gerne als Debugger, was vorrangig aber daran liegt, dass ich VS auch auf der Arbeit benutze und es entsprechend gewöhnt bin. Visual Studio ist für mich derzeit der Hauptgrund für eine Windows-Installation.
CodeLite und Codeblocks unterstützen aber ebenfalls Step-By-Step-Debugger.
Glocke hat geschrieben:Und erstmal gefühlte Tausend Haltepunkte zu setzen, klingt für mich nicht nach effektiver Fehlersuche
Ich vermute, Du meinst effizient, denn nicht effektiv wäre ja, dass der Fehler drin bliebe.
Fehlersuche ist niemals effizient, deswegen lernt man als Informatiker ja auch, Projekte hinreichend zu planen, um Fehler zu vermeiden. Die Realität lernt einen dann wieder, dass sich sowieso nicht alles planen lässt und man die zusätzliche Zeit für's Debuggen lieber gleich mit einplant.
Glocke hat geschrieben:Lange Rede - kurzer Sinn: Wie debugge ich richtig?
-g beim GCC verwenden - damit fängt's an.
Damit man nicht anfangen muss, vorher durchaus mal -Wall -pendantic anwerfen und der clang-Compiler findet ebenfalls gute Warnhinweise. Auch das Kompilieren mit Visual Studio war noch einige Hinweise, so dass ich auf ein, zwei Bugs aufmerksam wurde. Unittests schreiben, um Bugs in kontrollierter Umgebung abzutesten - mindestens für kompliziertere Codeabschnitte, die nicht durchgehend verwendet werden.
Programmieren besteht gerne aus ca. 50-80% Debuggen. Du kannst das drücken, indem Du semantisch starke Sprachen auch ausnutzt: Templates (vermindert Redundanz), Mehrfachvererbung (vermindert Redundanz). Redundanz vermeiden: das erhöht die Verwendung der geschriebenen Codes, entsprechend fallen Fehler schneller auf. Const-Correctness verhindert, dass man Variablen überschreibt, obwohl das in dem Moment nicht gewünscht ist. Das nachträgliche Einfügen von Const-Correctness in ein Projekt war mal eine Lehrstunde, weswegen ich keine Sprache mehr freiwillig anfasse, die Const-Correctness nicht unterstützt: Es wurden reichlich Bugs gefunden, die noch gar nicht aufgefallen waren.
Gute Programmierkenntnisse helfen also ebenfalls dabei, die Debugzeiten zu reduzieren. Die einzigen Bugs, die ich 2012 im Job zugewiesen bekam, haben andere geschrieben. Das ist Zufall, dass alles funktioniert, was ich 2012 geschrieben habe (bzw. keine Fehler aufgefallen sind), aber ein gefälliger.
Merke: Wer Ordnung hellt ist nicht zwangsläufig eine Leuchte.
Ich beantworte keine generellen Programmierfragen per PN oder Mail. Dafür ist das Forum da.
Und ab auf die ToDo-Liste damit