RTFM ist tot, lang lebe RTFM!

[c.rackwitz]

Hallo ihr alle.

Mittlerweile hab ich mich im Griff mit dem auf post antworten. Etwas moechte ich aber doch loswerden...

Der erste Eindruck zaehlt

keiner liest deinen code, wenn er wie hingerotzt aussieht. wenn du deinen stil noch nicht gefunden hast, oder einfach nur einen unzumutbaren hast (das entscheiden andere fuer dich), dann bemuehe doch BITTE einen code-reformatierer. einige gute IDEs und editoren helfen dir schon beim schreiben dabei. wenn deine(r) das nicht oder nicht ausreichend kann, besorg dir ein tool dafuer.

indent: http://www.linuxcommand.org/man_pages/indent1.html

dieses solltest du auf jedem unix finden. fuer windows kannst du auch einfach cygwin installieren (bei der installation "indent" mit anwaehlen).

Mach deine Hausaufgaben

ich setze voraus, dass du dein kapitel im buch fertig gelesen hast und keine features ausprobierst, die noch nicht erklaert worden sind. wir werden dir nicht sachen erklaeren, die dein buch sowieso erklaeren wird. sollte das der fall sein, lies einfach weiter und heb dir die fragen bis zum ende des buches auf.

dein programm hat also einen fehler. fein.

ist es eine fehlermeldung vom compiler oder vom system, google danach.

keine fehlermeldung? dein code hat vorhin ja noch funktioniert, also bevor du irgendwas dran geaendert hast. hoffentlich hast du nicht zu viel geaendert, denn weniger neuer code heisst weniger moegliche fehlerstellen.

du wirst in den neuen codeteilen irgendwelche (neuen) funktionen verwendet haben. google nach diesen und lies alles durch. vielleicht faellt dir was auf.

Heute mal Selbstkorrektur

inzwischen wissen wir ja, dass dein programm nicht funktionieren will. im vorherigen abschnitt hast du gelernt, immer nur ueberschaubare aenderungen vorzunehmen und sehr oft zu testen, ob dein code noch genau das tut, was du von ihm erwartest.

bei der fehlersuche kannst du nun zuversichtlich deine neueste aenderung verdaechtigen. der code macht offensichtlich etwas anderes als du erwartest. du musst nun rausfinden, warum dein geistiges bild vom code nicht mit der realitaet uebereinstimmt.

wie gleicht man seinen kopf mit der wirlichkeit ab?

printlining (geht immer)

printlining ist verwandt mit logging. du verstreust in deinem code ueberall textausgaben auf eine konsole (oder datei oder sowas). an hand dieser ausgaben verfolgst du variablen in deinem programm und auch welche teile des codes wann (in welcher reihenfolge) ausgefuehrt werden.

im einfachsten fall waere das ein puts("test"); , das du durch den code schiebst und immer wieder das programm laufen laesst. damit findest du raus, wo genau es kracht (dass also dein test-puts nicht mehr ausgefuehrt wird).

etwas mehr information bekommst du, indem du mit printf allerlei variablen ausgibst. das koennen sein: schleifenzaehlvariablen, irgendwelche strings, datenstrukturen marke eigenbau (verkettete listen z.b.)...

du verfolgst nun den programmfluss, siehst alle daten und auch den programmfluss vor dir. so bald das programm von deiner vorstellung abweicht, weisst du, wo du nachhaken musst.

nachhaken heisst in dem fall weiteres printlining bis du genau sagen kannst: die stelle ist kaputt. das kann z.b. eine funktion sein, die du benutzt, oder eine schleifenbedingung oder du verwendest falsche variablen/werte/zeiger.

der debugger (komfortabler und du musst dein programm nicht mit printlines vollmuellen)

wenn du mit einer IDE programmierst, kommt die sehr oft gleich mit einem debugger mit. in dem fall lies bitte die hilfedatei (im zweifelsfall F1 druecken und nach "debugger" suchen).

ist das nicht der fall, besorg dir GDB, den wohl bekanntesten debugger fuer C. die handhabung von GDB haben andere leute schon viel besser erklaert als ich es koennte oder wollen wuerde.

lies doch bitte einfach dies:

http://sourceware.org/gdb/onlinedocs/gdb.html

die Praesentation

wenn du bei deinen noetigen vorarbeiten auf keine loesung gestossen bist, lass dir hier helfen. du willst deine hilfe schnell und kompetent, also sollten diese tipps in deinem interesse sein.

entschuldigungen und andere einleitungen sind nicht noetig (und werden von einigen sowieso ueberlesen). stell dir die ganze prozedur so vor, als wuerdest du pizza bestellen: hallo, ich haette gern, ist in 20 minuten da.

um dir zu helfen, muessen wir ueber dein problem so viel wissen wie du.
konkret heisst das:

• was hast du vor (ideen und konzepte, kein code) und warum willst du das machen
• dein original code, nichts abtippen oder aus dem kopf reproduzieren. (in [cpp] tags kleiden und auf den eindruck achten)
• genug code, um das programm kompilieren zu koennen ("das sollte so kompilieren")
• gerade so viel code, damit das problem noch besteht (alles raus, was nicht zum problem beitraegt)
• was sollte der praesentierte code eigentlich machen
• was macht er stattdessen (fehlermeldungen usw hier)
• all deine eigenbemuehungen, das problem zu loesen (was kam beim googlen raus, was kam beim debugging raus,...)

du musst dir von uns nicht alles gefallen lassen, aber wenn jemand einsilbig oder mit ner URL antwortet, sei verstaendnisvoll und versuche aus den antworten so viel zu machen wie du kannst. den link einfach mal lesen (und auch weiterklicken), eventuell mal nach der einen silbe googeln, boardsuche bemuehen, in deinem buch nachschlagen,...

(ich bin jetzt nur noch gespannt, wie oft dieser post wieder ueberlesen wird. die chancen stehen gut, wenn man bedenkt, was hier so fuer threads aktuell sind, die im naechsten kapitel des lehrbuches schon geklaert worden waeren)