Eine Variable mehr und ich stürze ab
-
PLM schrieb:
Ich arbeite sonst nicht viel mit Debuggern
Geile Aussage eines Programmierers. Ist ungefähr genauso, als wenn ein Zimmermann sagen würde: "Ich arbeite sonst nicht viel mit Hämmern."
-
Es gibt auch ein c++ Forum
-
Mit jedem vernünftigen Debugger kann man sich auch an einen abgestürzten Prozess anhängen und sich den Callstack ansehen.
Ich bleibe dabei: Debuggen!
-
Du solltest jedenfalls mal alle Stellen ansehen, wo tendenziell über den gültigen Speicherbereich hinausgeschrieben werden könnte. Wie dir schon nahegelegt wurde, hilft der Debugger da ungemein.
EDIT: Und ja, im Debug-Modus wird u.U. der Speicher anders aufbereitet, so dass es schon mal vorkommt, dass man sich eigentlich den Heap zerschießt, beim Debuggen aber nichts davon merkt. Das ist aber absolut kein Grund, den Debugger nicht zu nutzen!
-
Geile Aussage eines Programmierers. Ist ungefähr genauso, als wenn ein Zimmermann sagen würde: "Ich arbeite sonst nicht viel mit Hämmern."
Lol. Auch eine geile Aussage eines Programmierers. Ist ungefähr genauso, als wenn ein Elektroniker sagen würde: "Ich rufe lieber gleich die Feuerwehr, ich bau' ja sowieso einen Kurzen !"
Also ich mein' ja nur, da muss ich den Herrn PLM schon ein bisschen verteidigen
Weil das mit dem Hammer is doch ein bisschen übertrieben, ne ? ^^Ich benutze einen Debugger genauso wenig wie PLM, da ich ihn schlicht und einfach noch NIE gebraucht habe, weil mein Code eigtl. immer einwandfrei läuft.
Und in den SELTENSTEN Fällen wenn er mal nicht läuft finde ich den Fehler auch so und IMHO schneller als wie wenn ich da erst einen Debugger anwerfen müsste...Schließlich kann man Fehler nicht nur mit dem Debugger ausfindig machen, sondern man kann zur Abwechslung auch mal ein bisschen mitdenken bei der Arbeit.
Ich mein' ja nur... hinsichtlich des Debuggers scheiden sich die Geister
-
Genau in die Kristall zu gucken ist besser als mal den Debugger zu befragen, wo es sich zerschießt.
-
Einen Clean-Build hast du mal probiert? Vielleicht wird irgendwas nicht sauber aktualisiert.
-
DebuggingIsForTheWeak schrieb:
Ich benutze einen Debugger genauso wenig wie PLM, da ich ihn schlicht und einfach noch NIE gebraucht habe, weil mein Code eigtl. immer einwandfrei läuft.
Und in den SELTENSTEN Fällen wenn er mal nicht läuft finde ich den Fehler auch so und IMHO schneller als wie wenn ich da erst einen Debugger anwerfen müsste...Schließlich kann man Fehler nicht nur mit dem Debugger ausfindig machen, sondern man kann zur Abwechslung auch mal ein bisschen mitdenken bei der Arbeit.
Ich mein' ja nur... hinsichtlich des Debuggers scheiden sich die Geister
Kann es sein, dass du eher kleine, private Projekte von wenigen tausend Zeilen (oder sogar weniger) durchziehst? Dann kann ich das durchaus nachvollziehen, dass du auch ohne Debugger klarkommst. Bei größeren Anwendungen ist ein Debugger allerdings unverzichtbar.
Was machst du denn eigentlich, wenn du mal Variableninhalte überprüfen musst? Ich vermute mal, du bastelst dir dann irgendeine Ausgabe (z.B. MessageBox), richtig? Dann kannst du auch gleich den Debugger nutzen und siehst, was du sehen musst, ganz ohne Code zu schreiben. Ganz zu schweigen von den anderen Möglichkeiten, die er so bietet...
Ich denke, man kann es so zusammenfassen: jedesmal, wenn du nicht auf Anhieb weißt, wo sich ein Fehler versteckt, spart der Debugger unheimlich Zeit. Daher finde ich den Vergleich mit dem Hammer doch recht passend.
Die eigentliche Frage ist doch: was spricht denn deiner Meinung nach gegen einen Debugger?
-
_matze schrieb:
Ich denke, man kann es so zusammenfassen: jedesmal, wenn du nicht auf Anhieb weißt, wo sich ein Fehler versteckt, spart der Debugger unheimlich Zeit. Daher finde ich den Vergleich mit dem Hammer doch recht passend.
Die eigentliche Frage ist doch: was spricht denn deiner Meinung nach gegen einen Debugger?
Kann es ein, daß deine bisherigen Projekte nur aus wenigen Zeilen Code bestehen, denn ich sehe das nicht so? Gerade bei größeren Anwendungen, ist ein Verzicht auf den Debugger oft Zeitsparender. Ein Beispiel: Ein Prozess, dessen Laufzeit > 1 h ist, stürzt am Ende ab. Wenn ich jedes mal im Debugger eine Stunde warten muß, bis ich den Fehler reproduzieren und analysieren kann, bin ich schneller, wenn ich lieber gleich das Hirn einschalte und den Code lese.
Fazit: Debugger sind nützlich aber es gibt auch andere gute Methoden.
mfg Martin
-
mgaeckler schrieb:
Kann es ein, daß deine bisherigen Projekte nur aus wenigen Zeilen Code bestehen, denn ich sehe das nicht so? Gerade bei größeren Anwendungen, ist ein Verzicht auf den Debugger oft Zeitsparender. Ein Beispiel: Ein Prozess, dessen Laufzeit > 1 h ist, stürzt am Ende ab. Wenn ich jedes mal im Debugger eine Stunde warten muß, bis ich den Fehler reproduzieren und analysieren kann, bin ich schneller, wenn ich lieber gleich das Hirn einschalte und den Code lese.
Fazit: Debugger sind nützlich aber es gibt auch andere gute Methoden.
mfg Martin
So ein Quatsch. Was hat denn die Anzahl der Zeilen mit der von dir genannten Laufzeit zu tun? Du kannst Software schreiben, die 1000 Zeilen groß ist, aber 2 Stunden braucht, um an einen gewissen Punkt zu kommen. Genauso gibt es Software, die 1 Million Zeilen hat, aber jeder Programmteil in wenigen Sekunden oder Minuten erreicht werden kann. Die Software, an der ich mitarbeite, ist 500.000 LOC groß (plus anderen, nicht in Zeilen ausdrückbaren Code), also nicht nur wenige Zeilen. Aber nicht jede Software hat einen Ablauf, wie du ihn beschrieben hast. Allerdings haben wir uns selbstverständlich auch Testunits geschaffen, um bestimmte Programmteile isoliert laufen zu lassen. Das wäre bei dem von dir genannten Beispiel auch ratsam, falls möglich.
Außerdem habe ich nicht behauptet, dass man ausnahmslos jedes Problem per Debugger lösen muss. Natürlich findet man manche Fehler schnell durch simples Ansehen des Codes, ganz ohne weitere Ausführung. Oft hat man ja auch einfach eine Ahnung. Ist das jetzt ein Argument gegen einen Debugger?! Sicher nicht.
Ich denke bei vielen "Debugger-Gegnern" ist es eher so, dass einfach die Praxis fehlt. Ich habe auch ohne Debugger Programmieren gelernt. Wenn man aber erstmal mit den Möglichkeiten vertraut ist, will man nicht mehr ohne. Im professionellen Umfeld wird du wohl auch niemanden finden, der komplett ohne Debugger arbeitet, denn schließlich kommt es auf Effizienz an, und die ist in vollem Maße nur mit Debugger gegeben. Ob es Einzelfälle gibt, die ohne lösbar sind (wie gesagt, das ist natürlich unbestritten), und wie häufig genau diese sind, ist irrelevant.
-
Programmieren ohne Debugger ist wie Autofahren ohne Bremspedal. Es geht, man kommt damit auch bis zum Supermarkt zwei Straßen weiter, aber es ist nur eine Frage der Zeit, bis man vor die Wand fährt.
Und beides sind völlig absurde Ideen.
Das Problem ist nur, dass der Debugger Anfängern, die ihn eigentlich am dringendsten benötigen, meistens lange verschwiegen wird. Ich erinnere mich an die Zeit, als ich Anfänger war, und ich zwar mal von einem Debugger gehört hatte, der aber irgendwo unter "schwarze Magie" lief. Wenn er in Anfängerbüchern überhaupt erwähnt wird, dann meistens im vorletzten Kapitel oder Anhang - ist es da ein Wunder, dass sich die Wenigsten anfänglich damit befassen? Letztendlich hat sich natürlich herausgestellt, dass der Debugger eigentlich sehr einfach zu bedienen und von unvergleichlicher Nützlichkeit ist, und heute bin ich der Ansicht, dass der Debugger in jeder Programmiervorlesung und in jedem Anfängerbuch spätestens in der zweiten Lerneinheit eingeführt gehört.
"Debugging is for the weak"? Besser schwach als dämlich, kann ich nur sagen.
Was das Zeitargument angeht, testen musst du das ganze hinterher sowieso. Wenn du in der Lage bist, eine Umgebung aufzusetzen, in der es weniger als eine Stunde dauert, das ganze laufen zu lassen (bzw. nur die entsprechende Code-Einheit testen kannst, wie _matze sehr richtig bemerkt), ist das Argument hinfällig. Ist das nicht der Fall, bist du trotzdem deutlich besser dran, einmal mit dem Debugger zu kucken, was wirklich kaputt ist, als wild im Nebel zu stochern. Natürlich ist ersteres der Normalfall.
-
Was für mich in der Vergangenheit oft der echte Debugging-Horror war, waren Aufenthalte beim Kunden. Da muss dann unter Zeitdruck neue SW aufgespielt werden, die läuft plötzlich nicht vernünftig (weil eine echte Kundenumgebung manchmal einfach was anderes ist, so sehr man auch versucht, diese in der Firma zu simulieren), und man holt seinen Entwicklungsrechner aus dem Auto, um sich die Stelle mal anzusehen. Da an diesem sämtliche Geräte fehlen, die ein Laufen der SW (bzw des betreffenden Teils der SW) überhaupt erst ermöglichen würden, fängt man an, sich Funktionen Zeile für Zeile durchzusehen auf der Suche nach dem bösen Fehler. Klappt das nicht, bastelt man schnell mal Ausgaben in die Logdatei ein, rennt mit der DLL zum Kundensystem, kommt mit neuen Erkenntnissen wieder zum Entwicklungsrechner, bastelt weitere Ausgaben usw... Das alles passiert natürlich unter enormem Zeitdruck und unter widrigen Umständen (z.B. fremde Peripherie; ich hasse es, wenn mir meine Makrotasten fehlen
). Der Kunde drängt darauf, dass die Maschine wieder produktiv laufen muss. Im schlimmsten Fall muss zeitweilig das Backup der alten Version eingespielt werden, so dass einem selbst die Logausgaben zur weiteren Analyse fehlen. Grauenhaft!Aber selbst für solche Fälle gibt es eine vernünftige Lösung: Remote Debugging. Sowas wurde bei uns bislang überhaupt nicht gemacht, aber letztens mal von mir und ein paar Kollegen angestoßen, so dass wir hoffentlich in Zukunft die obige Situation nie wieder in dem Maße erleben müssen.
Fazit: wer zuhause sitzt und alle Zeit der Welt hat, kann sich natürlich sein 2000-Zeilen-Programm in aller Ruhe zig mal durchlesen und im Kopf durchspielen, bis er den Fehler gefunden hat (ob das sinnvoll ist, darf auch bezweifelt werden, es ist aber vielleicht machbar). Vielleicht dauert das 20 Sekunden, vielleicht auch 2 Stunden. Wer allerdings auch mal Zeitdruck hat und eine größere Anwendung, muss jedes ihm zur Verfügung stehende Mittel nutzen, und da ist der Debugger fast immer die erste Wahl.
-
Vielleicht interessiert ja dein einen oder anderen mittlerweile, was ein Debugger so alles kann. Wir haben hier auch einen netten Artikel zu dem Thema. Der bezieht sich zwar noch auf das Visual Studio 6, aber das ist eigentlich egal. Dort kann man mal nachlesen, welche Möglichkeiten es so gibt. Die sind wahrscheinlich jemandem, der bislang noch nicht mit Debugger gearbeitet hat, gar nicht bewusst (schrittweises Ausführen des Codes, Callstack ansehen, Assertions, Variablenwerte zur Laufzeit überprüfen und sogar ändern, Haltepunkte, Datenhaltepunkte uvm.).
http://magazin.c-plusplus.net/artikel/Debuggen mit VCPlusPlus6
-
_matze schrieb:
So ein Quatsch. Was hat denn die Anzahl der Zeilen mit der von dir genannten Laufzeit zu tun?
Ich habe mit keiner Silbe erwähnt, daß es einen Zusammenhang zwischen der Anzahl der Lines of Code und den Laufzeitverhalten einer Anwendung gibt.
Du scheinst aber einen Zusammenhang zwischen der Benutzungshäufigkeit eines Debuggers und der Anzahl der Lines of Code zu sehen. Auf diesen Misstand wollte ich nur aufmerksam machen.
Wer bei 2000-Zeilen und mehr gar keinen Plan hat, wo der Fehler stecken könnte, hat schon im Vorfeld einen Fehler gemacht. Für den mag ein Debugger das probate Mittel zur Fehleranalyse sein. Normalerweise beschränkt sich aber der Bereich in dem der Fehler zu suchen ist, auf wenige Lines of Code. Dann bin ich häufig mit simpler Codeanalyse schneller am Ziel.
Ein Debugger ist nicht das einzige Mittel zur Fehleranalyse und nicht immer das beste. Mehr wollte ich nicht sagen.
mfg Martin
-
mgaeckler schrieb:
Ich habe mit keiner Silbe erwähnt, daß es einen Zusammenhang zwischen der Anzahl der Lines of Code und den Laufzeitverhalten einer Anwendung gibt.
Hm, sorry. Ich habe mir deinen Post nochmal durchgelesen. Das hast du tatsächlich nicht gesagt. Da hatte ich wohl gelesen, was ich lesen wollte.
mgaeckler schrieb:
Ein Debugger ist nicht das einzige Mittel zur Fehleranalyse und nicht immer das beste. Mehr wollte ich nicht sagen.
Na ja, so allgemein formuliert könnte man das natürlich stehen lassen. Ich finde es aber wichtig, den Leuten hier, die dem Debugger eher ablehnend entgegenstehen (und das vermutlich wegen Unwissenheit bzw. fehlender Praxis), klarzumachen, dass er ein unheimlich nützliches Werkzeug ist, das unbedingt genutzt werden sollte. Natürlich nicht in ausnahmslos jedem Fall (diese Feststellung halte ich für selbstverständlich), aber doch häufig. Außerdem kann auch nach Finden des Fehlers (je nach Art des Fehlers und seiner Behebung) durch eine Debug-Session festgestellt werden, ob man da auch wirklich vernünftig gearbeitet hat. Es gibt schließlich Programmierfehler, die nicht immer zur Laufzeit auftreten bzw. durch das Laufzeitverhalten immer sichtbar werden. Da kann es helfen, mal die betreffenden Variablen zu checken und sich somit sicher zu sein, dass wirklich nichts mehr passieren kann.
-
_matze schrieb:
Na ja, so allgemein formuliert könnte man das natürlich stehen lassen. Ich finde es aber wichtig, den Leuten hier, die dem Debugger eher ablehnend entgegenstehen (und das vermutlich wegen Unwissenheit bzw. fehlender Praxis), klarzumachen, dass er ein unheimlich nützliches Werkzeug ist, das unbedingt genutzt werden sollte. Natürlich nicht in ausnahmslos jedem Fall (diese Feststellung halte ich für selbstverständlich), aber doch häufig. Außerdem kann auch nach Finden des Fehlers (je nach Art des Fehlers und seiner Behebung) durch eine Debug-Session festgestellt werden, ob man da auch wirklich vernünftig gearbeitet hat. Es gibt schließlich Programmierfehler, die nicht immer zur Laufzeit auftreten bzw. durch das Laufzeitverhalten immer sichtbar werden. Da kann es helfen, mal die betreffenden Variablen zu checken und sich somit sicher zu sein, dass wirklich nichts mehr passieren kann.
Das klingt schon viel besser. Jetzt passt es.
Dein erster Post klang noch ziemlich anmassend. Vor allen weil Du auch auf die Anzahl der Codezeilen Bezug genommen hast. So wie jetzt unterschreibe ich das auch.
mfg Martin
-
mgaeckler schrieb:
Vor allen weil Du auch auf die Anzahl der Codezeilen Bezug genommen hast.
Na ja (ja, ich muss jetzt noch mal hinterherpfeffern
), das rein auf die Anzahl der Zeilen zu beziehen, war natürlich ein bisschen naiv ausgedrückt. Aber mit der Komplexität des Codes hat es schon was zu tun, finde ich. Die definiert sich aber nicht nur über die Codegröße.
