Kleines Problem bei 'ner C-Übungsaufgabe
-
PrettyP schrieb:
Ich begrüße es, wenn sich jemand von Anfang an daran gewöhnt, unabhängig vom Debugger zu sein.
Die mir bekannten Debugger haben - sicherlich auch durch Bedienungsfehler oder Unwissen - bisher nicht gänzlich mit der von mir gewünschten Leistung geglänzt und ein simples printf mit getchar bringt bei womöglich weniger Aufwand in einer schmeichelnden Anzahl von Fällen brauchbare Ergebnisse.
Sicherlich gibt es genug Anwendungsfälle, in denen ein Debugger kaum wegzudenken wäre, aber für 3 simple printfs ist die Nutzung eines Debuggers nicht zwingend notwendig.
Wenn durch Fehlformatierungen im printf dann eben Nonsens rauskommt, ist das nur ein Schritt auf dem Weg der Besserung, weil man durch solche Fehler prima lernt...
Wenn du schon einräumst, die Debugger eventuell fehlbedient zu haben, kannst du genaugenommen kaum ein Urteil darüber abgeben, oder?
In diesem Fall hat der Weg ohne Debugger zu fehlerhaften Ergebnissen geführt. Der Debugger hätte verraten, dass alles bis zum printf völlig ok abläuft und der Fehler da liegen muss. Und nebenbei denke ich nicht, dass Arbeiten ohne Debugger irgendwie dafür sorgt, dass man weniger aus seinen Fehlern lernt. Die Fehler passieren sowieso, und in (hoffentlich) beiden Fällen findet man deren Ursache und behebt sie. Nur dass man sich mit Debugger die Arbeit spart, eigene Debuggingmechanismen (Ausgaben) zu basteln.
PrettyP schrieb:
Wohingegen in diesem Falle die Nutzung des Debuggers nicht dazu geführt hätte, dass etwaige Formatstring-Fehler zukünftig mal für Probleme sorgen...
Diesen Satz überdenkst du besser noch mal.
-
Deinen Münzvergleich solltest du auch noch mal anschauen.
Der ist immer wahr.Annahme einwurf = 1, dass ist einwurf != 2
einwurf = 1; if (einwurf !=1 || einwurf !=2 || einwurf !=5) # unwahr oder wahr oder wahr -> wahr
-
_matze schrieb:
Wenn du schon einräumst, die Debugger eventuell fehlbedient zu haben, kannst du genaugenommen kaum ein Urteil darüber abgeben, oder?
Mache ich aber! Wenn ein Debugger nicht für "jeden Depp" passende Ergebnisse liefert, kann ich für die "einfachen" Anwendungen gleich beim printf bleiben.
_matze schrieb:
PrettyP schrieb:
Wohingegen in diesem Falle die Nutzung des Debuggers nicht dazu geführt hätte, dass etwaige Formatstring-Fehler zukünftig mal für Probleme sorgen...
Diesen Satz überdenkst du besser noch mal.
Denk Dir einfach noch ein nicht dazu - such dir die Stelle aus und sei glücklich, dass Du einen meiner zahlreichen Sinnfehler entdeckt hast. Ich denke, man kann sich ungefähr zusammenreimen, was ich gemeint haben könnte.
-
PrettyP schrieb:
Mache ich aber! Wenn ein Debugger nicht für "jeden Depp" passende Ergebnisse liefert, kann ich für die "einfachen" Anwendungen gleich beim printf bleiben.
Hm, also ich nutze das VS2008, und da gehts so: F9 drücken, um einen Haltepunkt zu setzen. Programm starten. Variableninhalte ansehen! Was ist daran jetzt so schwer? Wieso sollte ich aufwändig eine printf-Zeile schreiben, wenn ich doch das gleiche ohne jede Tipparbeit und vor allem ohne Fehleranfälligkeit erreichen kann (denn beim printf-Aufruf kann sich schnell man ein Fehlerchen einschleichen)? Und was soll das jetzt mit einfachen Anwendungen zu tun haben? Eine Debug-Ausgabe selbst zu schreiben dauert immer länger, als einen Haltepunkt zu setzen. Die Ersparnis und die gewonnene Sicherheit sind eigentlch gleich.
-
Nicht jeder genießt den Komfort der wunderbaren Windowswelt. Unter anderen Bedingungen gibts durchaus auch tendenziell umständlichere Debugger.
Abgesehen davon bin ich nicht sicher, wie sehr einem der Debugger bei der Erkennung eines fehlerhaften Formatstrings hilfreich wäre, wenn man nicht auch von selbst drauf käm.
Naja, Du hast Recht, ich liege falsch. Printf ist böse und umständlich und Debuggen ist prima.
-
PrettyP schrieb:
Naja, Du hast Recht, ich liege falsch. Printf ist böse und umständlich und Debuggen ist prima.
Du bist echt'n Vogel, wer sagt denn, daß printf() überhaupt geht? Tut's bei mir normalerweise nicht (arbeite mit embedded Controllern) und wenn, geht der Stream eigentlich immer auf das falsche Gerät. Die Dödelei mit Headeranpassung und Neucompilierung der Standardlibs und dann so ins Projekt einbinden, daß sich andere nicht gestört fühlen, das ist echt *würg*.
Mal stehenbleiben und 'nen Wert ausgeben, meinetwegen, schwierig wird's halt bei conditional breaks, also nach Anzahl der Durchläufe oder Triggern auf 'nen Variableninhalt. Da kannst Du mir nicht erzählen, daß Du mit Deinem Rumproggen schneller bist, als die Eigenschaften eines Breakpoints zu bearbeiten. Meistens hab ich sowieso 5 - 10 Breakpoints aktiv, da sind wir schon bei der nächsten Fehlerquelle: Weißt Du noch, wo überall Deine printfs standen? Macht sich nicht so pro aus, plötzlich Debug- Output in der Release zu sehen. Der Compiler haut brav alles weg, wenn ich auf den Release- Button drücke.
Ja, es gibt so Makrosammlungen zum Debuggen, aber ich muß mir ja nicht von hinten durchs Knie ins Hirn schießen, wenn es anders geht. Die 1980er sind vorbei!
Tatsächlich fasse ich Projekte nicht mal mehr mit der Kneifzange an, wenn nicht ein zeitgemäßer Debugger verfügbar ist. Dazu ist mir meine Zeit und die meiner Kunden zu schade!
-
Vielen Dank für eure Hilfe!
Das mit dem float wird's vermutlich sein.Ich habe jetzt aber ein neues Problem, das ich nicht so recht deuten kann. Der Compiler, ich arbeite mit Bloodshed Dev-C++, gibt mir folgende Fehlermeldung aus.
42 H:\Getraenkeautomat.cpp non-lvalue in assignment
Die betroffene Zeile ist dabei folgende:
41 // Kontrolle ob eine der erlaubten Münzen eingeworfen wurde 42 if (muenze = 1 || muenze = 2 || muenze = 5) { 43 muenze +=einwurf;Ich habe also den von DirkB schon angesprochenen Fehler korrigiert. (So müsste es ja funktionieren.
)Natürlich konnte ich das überarbeitete Programm deswegen nicht kompilieren. Habe nach der Fehlermeldung schon gegoogelt, aber konnte mir darauf gerade keinen Reim machen. Würde mir schon helfen, wenn man mir die Bedeutung der Fehlermeldung erklären kann.
-
Der Vergleichsoperator ist ==, du verwendest dort Zuweisungs-Operatoren.
-
Ah, ich Depp! Natürlich!
Besten Dank!Ich hab' jetzt alle Probleme beheben können und das Programm läuft wie gewünscht. (Gab noch andere Fehler, aber die waren danach kein Ding mehr)
Ich bedanke mich bei allen für den guten Support.
-
PrettyP schrieb:
Nicht jeder genießt den Komfort der wunderbaren Windowswelt. Unter anderen Bedingungen gibts durchaus auch tendenziell umständlichere Debugger.
Abgesehen davon bin ich nicht sicher, wie sehr einem der Debugger bei der Erkennung eines fehlerhaften Formatstrings hilfreich wäre, wenn man nicht auch von selbst drauf käm.
1. Auch, wenn die Bedienung etwas umständlicher wird, lohnt es sich doch, diese zu erlernen. Der Mehrwert sorgt in der Regel für effizienteres und weniger fehleranfälliges Arbeiten. pointercrash hat schon Recht, es gibt weitaus schlimmere Beispiel als dieses hier. Wenn ich wissen will, wann sich eine Variable ändert, erstelle ich einen Datenhaltepunkt. Das ist eine Sache von Sekunden. Was machst du? Wert der Variablen in einer temporären Variable speichern, ständig vergleichen und im Falle des Nichtübereinstimmens eine Ausgabe per prinft/MessageBox/sonstwas? Was ist, wenn die Variable an weitere Funktionen weitergereicht wird? Baust du so eine Überprüfung dann in jede Funktion ein? Wie gesagt, ich erstelle einen Datenhaltepunkt, mehr nicht.
2. Hier ist doch nicht der Fehler an sich sondern die Hinführung zum Fehler wichtig. Wenn man sich durch den Code hangelt und jeden Schritt überprüft, kommt man irgendwann beim printf an und weiß, dass alle Variablen die gewünschten Werte halten. Also bleibt bei fehlerhafter Ausgabe nur die Ausgabefunktion selbst übrig. Bei dieser selbst kann dir der Debugger auch nicht mehr helfen (aber eventuell der Compiler, zumindest bei unerkannten Platzhaltern; nicht in diesem Fall). Aber um dahinzukommen, dass es diese eine Zeile sein muss, würdest du nun wieder anfangen, eventuell sogar mehrere Debugausgaben zu basteln. Ich drück nur ein bisschen auf den F-Tasten rum und komme sicher schneller ans Ziel.
PrettyP schrieb:
Naja, Du hast Recht, ich liege falsch. Printf ist böse und umständlich und Debuggen ist prima.
Absolut richtig erkannt!
