Wie man Probleme nachstellbar und nachvollziehbar macht

Oft findet man hier im Forum Fragen von Neulingen mit Problemen beim Übersetzen ihrer Programme oder zur Laufzeit. Manche liefern dazu garkeinen Code, andere nur spärliche Brocken oder aber hunderte irrelevanter Zeilen, wieder andere posten ungetesteten Pseudocode, der haufenweise Proleme hat, nur nicht das, um welches es geht. Weder mit dem einen noch mit dem anderen Extrem ist uns und euch geholfen, daher soll hier ein kleines Tutorial folgen, wie man den relevanten Code postet - und nur den.

Wenn der Code nicht kompiliert/linkt

Es muss zwischen Compilerfehlern und Linkerfehlern unterschieden werden. Erstere haben auf allen aktuellen Compilern eine Angabe der Quelldatei und der Zeile, in der der Fehler auftritt. Letztere haben das nicht immer. Unter MSVC haben Compilerfehler einen Fehlercode Cxxxx und Linkerfehler LNKxxxx, wobei xxxx eine Ziffernkombination ist.
Grundsätzlich solltest du immer die Fehlermeldung mit angeben, allerdings auch nur eine, nicht einen ganzen Haufen. Nach einem Fehler sind andere Fehlermeldungen häufig Folgefehler, auch wenn man das nicht auf den ersten Blick sieht. Versuche auf jeden Fall, die Meldung zu verstehen, um zu wissen, was zum Fehler gehört und was nicht. Ein paar Brocken Englisch sind (bei englischen Compilern) von Nutzen. Wenn du Wörter aus den Fehlermeldungen nicht verstehst, lass sie dir übersetzen oder google nach den Fachbegriffen - oder der gesamten Fehlermeldung.
Gib von vornherein an, welchen Compiler und welche IDE du benutzt (nicht verwechseln!), außerdem ist es gut zu wissen, welche Compileroptionen du gewählt hast (wenn du einfach aus der IDE heraus baust ohne was geändert zu haben sag das explizit dazu). Beachte Warnmeldungen und poste sie ggf. auch noch. Die meisten Warnungen weisen auf mögliche Fehlerquellen hin und sollten behoben werden.

Linkerfehler

Linkerfehler sind sehr häufig fehlende Funktions- oder Variablendefinitionen. Siehe dazu den FAQ-Eintrag zu undefined references.
Das Gegenteil dazu ist der Fehler "multiple definition of..." - er erscheint meist, weil eine globale Variable oder eine freie, nicht-inline Funktion in einem Header definiert wurde.

Linkerfehler beziehen sich meistens auf ein bestimmtes Symbol, d.h. einen Funktionsnamen oder Variablennamen. Jeder Code, der diesen Namen enthält, ist hierbei relevant, d.h. aufrufende Funktionen, die Funktion/Variable selbst, die zugehörige Klasse, wenn es sich um eine Methode handelt. Beim Reduzieren des Codes (s.u.) sollten unbetiligte Funktionen und Variablen komplett entfernt werden. Wenn sich die Fehlermeldung auf eine Funktion bezieht, kann ihre Funktionalität normalerweise auf wenige Zeilen reduziert werden.

Compilerfehler

Compilerfehler betreffen normalerweise nur eine Handvoll Variabeln und Funktionen. Für das Nachstellen solcher Fehler wird nur eine .cpp und die (direkt oder indirekt) eingebundenen Header benötigt, alles weitere ist überflüssig. Tritt der Fehler in einer Funktionsdefinition auf, dann ist das die einzige Definition die man braucht, alle anderen Funktionen dürfen beim Reduzieren auf Deklarationen zusammengeschrumpft werden (beteiligte Funktionstemplates ausgeschlossen).

Ein einzelner Compilerfehler kann bei Templates viele Zeilen umfassen, wenn eine fehlerhafte Benutzung eines Templates an einer Stelle erst viele Instantiierungsstufen tiefer zu einem Fehler führt. Bei Template-Fehlern (z.B: in der Standardbilbiothek) solltest du daher immer sicherstellen, dass du die wesentlichen Teile der kompletten Fehlermeldung einsetzt, nicht nur die erste Zeile. Dazu gehören vor Allem die Zeilen, die deinen eigenen Code betreffen und der eigentliche Fehler.

Laufzeitfehler

Laufzeitfehler sind am schwierigsten zu reduzieren, weil hier oft nicht klar ist, in welcher Ecke was schief läuft. Aus dem Grund ist es wichtig, den Fehler zu lokalisieren, dazu ist es unumgänglich, sich mit der Benutzung eines Debuggers vertraut zu machen.
Wenn das Debuggen nichts hilft, können wir natürlich gerne weiterhelfen. Dazu brauchen wir neben dem Code eine möglichst genaue Beschreibung des Verhaltens, das ihr erwartet und des Verhaltens, das ihr tatsächlich bekommt.

Den Code reduzieren

Wenn du hier ins Forum kommst um eine Lösung für das Problem zu finden, heißt das, dass du schon einige Zeit suchst (bei Google, in deinem Code, im Buch deiner Wahl...). Um hier zügig eine Antwort zu bekommen investierst du am Besten noch ein kleines Bisschen mehr Zeit in die Kürzung und FOrmatierung deines Codes, und das geht so:

• Sichere deinen Code und lege eine Kopie davon an. (z.B. einen neuen branch in deiner Versinskontrolle) Von jetzt an arbeitest du auf der Kopie.
• Lösche großzügig die Teile raus, von denen du sicher bist, dass sie zum Problem nichts beitragen. (Funktionen, Klassen, #includes, ...)
• Übersetze den Code und stell sicher, dass du genau die selben Fehler hast wie vorher, nicht mehr und nicht weniger.
• Ersetze komplizierte Funktionalität Schrittweise durch was einfacheres, z.B. Funktionsaufrufe durch dummy-Werte usw. Auf die Weise reduzierst du die Abhängigkeiten deines Codes von weiteren Headern usw., die du dadurch auch rauswerfen kannst.
• Übersetze nach jedem Schritt und stell sicher, dass du genau die selben Fehler hast wie vorher, nicht mehr und nicht weniger.
• Verkleinere deine Klassen: entferne Membervariablen und Methoden, die den Fehler nicht beeinflussen.
• Übersetze...
• Ersetze #includes von eigenen Headern durch den Inhalt der Header, so dass du weniger Dateien bekommst.
• Wenn du in einem der Schritte neue Fehler bekommst, behebe sie oder mache den Schritt rückgängig.
• Wenn du in einem der Schritte deinen Fehler nicht mehr bekommst, denk drüber nach, ob dir das einen Hinweis gibt, woher der Fehler kommen könnte. Mache den Schritt rückgängig (Versionskontrolle hilft!) und fahre mit kleineren Schritten fort, den Fehler einzukreisen.

Du kommst zu einem Punkt, in dem du den Code nicht mehr weiter reduzieren kannst. Typischerweise hast du ca. 20-60 Zeilen, verteilt auf 1-5 Dateien.
Diesen Code kopierst und postest (nicht Abtippen!) du jetzt komplett zu deiner Fragestellung (und Fehlermeldung, Compiler, -optionen...):

• Lasse nichts weg, damit wir den Code einfach nur zu kopieren brauchen um den Fehler nachstellen zu können.
• Benutze die [cpp]-Tags (Button "C/C++" unter den Smileys)
• Rücke deinen Code ordentlich ein (hast du ja sicherlich sowieso, oder?)
• Schreibe mit Kommentaren die Namen der einzelnen Sourcen und Header vor die Codeabschnitte
• Trenne den Code verschiedener Dateien sichtbar voneinander - entweder durch mehrere Leerzeilen oder indem du sie jeweils in einen eigenen [cpp]-Tag setzt.

Zu viel Aufwand? Du möchtest, dass sich zig Leute hier mehr als nur einen Augenblick mit deinem Problem beschäftigen. Also solltest du auch bereit sein, dafür entsprechend viel Zeit zu investieren. Je mehr Mühe du dir gibst, desto leichter machst du es anderen, dir zu helfen, und desto wahrscheinlicher ist es, dass jemand sich auch wirklich mit deinem Problem beschäftigt.

**Danke!
**
Ich würde noch ändern (ich möchte nicht direkt in deinem Beitrag rumpfuschen):
- Bei Fehlermeldungen ist die erste Meldung die wichtigste, alles danach kann ein Folgefehler sein.
- Man sollte versuchen Fehlermeldungen wenigstens so weit zu verstehen, dass man die ganze erste Fehlermeldung hier postet. Wie du schon erwähnt hast, tritt das sehr oft bei Templates auf, aber hier wurden auch schon sehr oft andere Fehlermeldungen nach der ersten Zeile abgeschnitten, weil die Leute kein Englisch können (oder eher, weil sie gar nicht erst versuchen, die Meldung zu verstehen)
- Warnoptionen erwähnen. Viele typische Laufzeitfehler (besonders wenn man eher C als C++ macht) und sogar manche Compiler- und Linkerfehler können durch Beachten von Warnungen abgeschaltet werden.
- Linkerfehler haben (zumindest beim GCC) auch eine Angabe der Quelldatei mit einer kryptischen Positionsangabe. Das könnte in deinem Text missverstanden werden. Das sieht dann beispielsweise so aus:

example.cpp:(.text._ZN9igzstreamD1Ev[_ZN9igzstreamD1Ev]+0x67): undefined reference to `gzstreambase::~gzstreambase()'

Ich würde noch ändern (ich möchte nicht direkt in deinem Beitrag rumpfuschen):

Danke fürs Feedback, darf gerne ergänzt werden

[*]Ersetze #includes von eigenen Headern durch den Inhalt der Header, so dass du weniger Dateien bekommst.

Meinst du das ernst?

pumuckl schrieb:

[*]Ersetze #includes von eigenen Headern durch den Inhalt der Header, so dass du weniger Dateien bekommst.

Meinst du das ernst?

Ja natürlich. pumuckl will darauf hinaus, dass ein Post im besten Fall genau 1 C/C++ Tag enthält, in dem sich ein kompilierbares Minimalbeispiel befindet.

Hacker schrieb:

pumuckl schrieb:

[*]Ersetze #includes von eigenen Headern durch den Inhalt der Header, so dass du weniger Dateien bekommst.

Meinst du das ernst?

Ja natürlich. pumuckl will darauf hinaus, dass ein Post im besten Fall genau 1 C/C++ Tag enthält, in dem sich ein kompilierbares Minimalbeispiel befindet.

Ich dachte er meint es allgemein bezogen :shame-on-me:

Ich kann aber auch noch beitragen: Mann soll umbedingt C&P verwenden, sonst wird oft Verwirrung gestiftet.

Ich kann aber auch noch beitragen: Mann soll umbedingt C&P verwenden, sonst wird oft Verwirrung gestiftet.

Und wie viele Neulinge wissen was C&P heißt?... googlen dann und finden "C+P Möbelsysteme - Möbel für Menschen". Schreib es bitte aus.

Hacker schrieb:

Ich kann aber auch noch beitragen: Mann soll umbedingt C&P verwenden, sonst wird oft Verwirrung gestiftet.

Und wie viele Neulinge wissen was C&P heißt?... googlen dann und finden "C+P Möbelsysteme - Möbel für Menschen". Schreib es bitte aus.

Hahaha

Das Problem bei nicht Copy&Paste ist, dass dann Leute kommen und sich beschweren mit Beiträgen wie: Das lässt sich gar nicht compilieren, schlechtes Codebeispiel, blablabla. Damit schweift man ab. Den Code allerdings direkt zu kopieren ist besser. Dann kann man Flüchtigkeitsfehler sowie ein vergessenes Semikolon schneller abhaken.

Dummerweise aber tl;dr
Und vermutlich auch tl;dr für die Leute an die es gerichtet ist

Dummerweise aber tl;dr
Und vermutlich auch tl;dr für die Leute an die es gerichtet ist

Was!? Das geht doch noch voll klar. Im Gegensatz zu anderem...

@hustbaer: Dass es wenige vor ihrem ersten Post lesen werden ist mir bewusst. Denen die zu faul sind ist aber so oder so nicht zu helfen. Ich habs nur einmal sauber hinschreiben wollen, weil ein Link darauf einfacher zu posten ist als jedesmal zu erklären, was mit minimalem kompilierbarem Beispiel gemeint ist.

Allmählich sind unsere wichtig-Threads aussagekräftig genug dass man einfach schreiben kann "du liest unseres nicht, warum sollten wir dann deins lesen".

[*]Ersetze #includes von eigenen Headern durch den Inhalt der Header, so dass du weniger Dateien bekommst.

Wer das mit Standard-Headern versucht wird eh nicht viel Spaß daran haben

pumuckl schrieb:

[*]Ersetze #includes von eigenen Headern durch den Inhalt der Header, so dass du weniger Dateien bekommst.

Wer das mit Standard-Headern versucht wird eh nicht viel Spaß daran haben

Würde das Wort eigen im Originalbeitrag ruhig hervorheben. Ich traue den Leuten alles zu

pumuckl schrieb:

pumuckl schrieb:

[*]Ersetze #includes von eigenen Headern durch den Inhalt der Header, so dass du weniger Dateien bekommst.

Wer das mit Standard-Headern versucht wird eh nicht viel Spaß daran haben

Würde das Wort eigen im Originalbeitrag ruhig hervorheben. Ich traue den Leuten alles zu

Ich glaube jeder, der so intelligent ist diesen Beitrag zu lesen (respekt!), ist intelligent genug Selbstverständlichkeiten vom Kontext abzuleiten.

Würde das Wort eigen im Originalbeitrag ruhig hervorheben.

done. Und die Diskussion hier mal abgeschnibbelt

Ich glaube jeder, der so intelligent ist diesen Beitrag zu lesen (respekt!), ist intelligent genug Selbstverständlichkeiten vom Kontext abzuleiten.

Siehe:

Hacker schrieb:

pumuckl schrieb:

[*]Ersetze #includes von eigenen Headern durch den Inhalt der Header, so dass du weniger Dateien bekommst.

Meinst du das ernst?