Darling, why don’t you just look at the std::map?

Ich hasse es, STL-Container debuggen zu müssen.

In Microsofts Visual Studio kann man sich ja im Debugger recht schön Element für Element den Inhalt einer std::map, eines std::sets oder eines std::vectors anzeigen lassen. Dummerweise kenne ich keine einfache Möglichkeit, sich die Speicherstelle anzeigen zu lassen, an der ein Element oder die size dieses Containers liegt, um auf diese Speicherstelle einen Breakpoint zu setzen, der mich alarmiert, wenn sich da was ändert.

Beispiel: ich habe eine std::map von Daten-Varianten, die ihrerseits eine std::map verschiedenen Ressourcen enthalten, die ihrerseits eine std::map von Kapazitätsobjekten dieser Ressourcen enhalten, die ihrerseits eine std::map von den eigentlichen Kapazitätswerten enthalten. Irgendwo, irgendwie, irgendwann gehen mir manche dieser std::maps mit Kapazitätswerten kaputt. Jetzt würde ich gerne herausfinden, an welcher Stelle im Programm das passiert, und dazu einen Daten-Haltepunkt auf der size dieser std::map anlegen. Das wäre schön praktisch: ich lasse das Programm laufen, und irgendwann, *blink*, meldet sich der Debugger, weil die Größe meiner std::map plötzlich bei drölfzig Milliarden liegt statt bei, sagen wir, 42.
Guter Plan.

Um sich den Speicherort ausgeben zu lassen, an dem man diesen Breakpoint setzen kann, muss man aber solche Verrenkungen unternehmen wie

&(m_pGanttViewCtrl->m_varMan
->m_variants._Myhead->_Left->_Myval.second
->m_pRessourcen->m_resMap._Myhead->_Right->_Myval.second
->m_pResKapazitaeten->m_capacities._Mysize)

womit der Debugger das erste Element der m_variants-map nimmt, dort dem Ressourcenpointer in seine m_resMap folgt, dort (in diesem Beispiel) das letzte Ressourcen-Element rausgreift, von dem er sich den Kapazitätenpointer und dessen m_capacities-map geben lässt, in der er dann _Mysize findet, wovon er sich schlussendlich die Speicherstelle ausgeben lässt.

Heute nacht habe ich mich in verschachtelten STL-Containern verlaufen, und alle waren knallbunt und riesengroß und enthielten jeweils noch ein ganzes Containerschiff voller Container, und die waren auch alle knallbunt und riesengroß und enthielten jeweils noch ein ganzes Containerschiff voller Container, und so weiter, und alle sollten sofort entladen werden, und ich musste doch noch was finden, aber ich wusste nicht mehr, was, und die Zeit drängte so und ich konnte es nicht finden, ich wusste ja nicht, wo es war, und dann — dann klingelte der Wecker.

Dichten und Debuggen und der Musenkuss

Ich hasse Programmieren.

Nein, eigentlich ja nicht. Aber manchmal halt schon. Heute zum Beispiel. Und heute war dummerweise ich schuld…

Das letzte Jahr habe ich mehr oder weniger damit zugebracht, fremden Code kennen zu lernen und zu debuggen. Irgendein Kollege kommt rein, mit mehr oder weniger roten Flecken im Gesicht, und sagt sowas wie: „Sag mal, Christian, Du bist doch jetzt derjenige, der für XYZ zuständig ist, oder?“
In dem Moment kriege ich immer schon Schweißausbrüche, denn ich weiß genau: die nächsten Stunden oder Tage darf ich mich wieder fluchend durch zigtausend Zeilen Programmcode wühlen, der unkommentiert und, hmmm, sonderbar strukturiert ist, und nach irgendwelchen obskuren Bugs suchen. Zwei Tage später bin ich zwar völlig aus meinem eigentlichen Projekt raus, aber immerhin ist der Bug behoben, ich habe das Programm mit seinen fünfzehn Millionen Optionen, Sondereinstellungen und Wahlmöglichkeiten besser kennengelernt, der Kunde ist glücklich und ein paar hundert Zeilen Code sind nebenbei wieder sauberer geworden. Das entschädigt ein wenig für die grauen Haare.

Nein, fremden Code debuggen zu müssen ist echt schlimm. So frustrierend! Da liest man Code, da testet man, da wälzt man Dokumentationen und googelt sich die Finger wund — nichts funktioniert!

Das einzige, was schlimmer ist, als stundenlang erfolglos fremden Code zu debuggen, ist, stundenlang erfolglos eigenen Code zu debuggen. Da kommt man sich noch viel blöder vor, und man kann nicht mal auf jemand anders schimpfen…

Debuggen ist sowieso der ungeliebte Teil des Programmierens, und auch neuen Code zu schreiben ist gelegentlich einfach mühsam und nervig. Aber manchmal… manchmal fluppt es halt einfach: der Algorithmus stimmt, das Programm kompiliert im ersten Versuch, und es läuft auch gleich fehlerfrei durch. Das ist selten, aber gelegentlich gellen in solchen Fällen Glücksschreie durchs Büro.

Hmmnja.

Wie kriege ich jetzt die Kurve zum Dichten? Einfach übergangslos umschwenken? OK:

Beim Dichten oder Schreiben ist es ähnlich: manchmal kriegt man ums Verrecken keinen gerade Satz auf das Papier, und den einen oder anderen Absatz streicht man fünfmal durch, bevor man annähernd zufrieden ist — und manchmal fängt man an und schreibt eine Kurzgeschichte oder ein Gedicht glatt und fehlerfrei runter. Zack, Unterschrift, fertig! Das ist selten, aber gelegentlich gellen in solchen Fällen Glücksschreie durchs Haus.

Irgendein schlauer Mensch hat mal sowas gesagt wie: „Es gibt Tage, da scheint einem alles zu gelingen. Keine Angst: das geht vorüber.“
Ja, das geht vorüber, und allzu oft passiert es auch sowieso nicht. Aber wenn einem sowas mal wieder passiert — hach…

Was für ein Genuss,
so ein Musenkuss!