Wieso ist das Programm ein Alptraum?

[Marc++us]

Programmierfachprofi schrieb:

Deine Sprungmarken erhöhen ebenfalls die Zeilenanzahl und somit die Fehleranfälligkeit.

Zeilenanzahl ist ungleich Komplexität, damit ohne Zusammenhang zur Fehleranfälligkeit.

Aber die Notwendigkeit Code zu duplizieren und bei Änderungen an jeder Duplikationsstelle mitzuändern ist extrem fehleranfällig.

Programmierfachprofi schrieb:

Außerdem kann ein Compiler so ein Konstrukt nicht mehr so gut optimieren, das dürfte das Totschlagargument für GOTO sein.

Hm? Woraus leitest Du das ab? Da diese Form der goto-Fehlerbehandlung gerade in Unix-Kernels verwendet wird UND deren Übersetzung ein Standardbenchmark für jeden Compiler ist, haben die mit hoher Wahrscheinlichkeit darüber nachgedacht.

Für den Compiler ist das goto ja nur ein weiterer Pfad... es gibt einmal den regulären Pfad, und dann welche mit goto. Der Compiler baut sich darauf seinen Ablaufgraph auf und optimiert entlang des Ausführungspfads. Es zwar richtig, daß man von goto aus jedem Kontext rausspringen kann, aber wenn das Programm übersetzt wird sind alle diese Exit-Punkte dem Compiler bekannt.

[seldon]

cooky451 schrieb:

seldon schrieb:

als der gleiche Code

Konsequent weitergedacht bedeutet das, dass keine Funktion mehr als eine Ressource reservieren darf.

Das hab ich damit nicht gemeint, sondern, dass eine Funktion, die sich mit Ressourcenallokation beschäftigt, (fast)* nur mit Ressourcenallokation beschäftigen sollte, und nicht mit der Verwendung selbiger. Das kann dann ruhig auch ne static-Funktion direkt über der verwendenden Funktion sein.

Damit hat man den fummeligen Teil an einer Stelle, kommt aus der Ressourcenanforderung in einem von zwei Zuständen wieder raus ("alles geklappt, Ressourcen angefordert" oder "ist was schief gegangen, alles schon wieder aufgeräumt") und ist einen Großteil der Komplexität los.

Wenn man in einer Funktion mehrere Ressourcen braucht, wird man, wie gesagt, die Kaskade nicht unbedingt los, aber man hat sie isoliert -- und eine Funktion, die sich nur mit der Anforderung von so Größenordnung drei Kontextobjekten beschäftigt, kriegt man mit oder ohne goto lesbar gebacken (ich mach das dann lieber ohne). Wenn man in einer Funktion deutlich mehr einzelne Ressourcenanforderungen hat, hat man aus meiner Sicht noch ganz andere Strukturprobleme -- das schlägt dann in die selbe Bresche wie die Funktionen-sollten-nicht-länger-als-50-Zeilen-lang-sein-Faustregel.

* nach Sachlage im Einzelfall zu beurteilen

[Programmierfachprofi]

Marc++us schrieb:

Programmierfachprofi schrieb:

Deine Sprungmarken erhöhen ebenfalls die Zeilenanzahl und somit die Fehleranfälligkeit.

Zeilenanzahl ist ungleich Komplexität, damit ohne Zusammenhang zur Fehleranfälligkeit.

Aber die Notwendigkeit Code zu duplizieren und bei Änderungen an jeder Duplikationsstelle mitzuändern ist extrem fehleranfällig.

Deswegen lagert man das in Funktionen aus, benutzt inline-ersetzung oder Funktionsmakros.

Programmierfachprofi schrieb:

Außerdem kann ein Compiler so ein Konstrukt nicht mehr so gut optimieren, das dürfte das Totschlagargument für GOTO sein.

Hm? Woraus leitest Du das ab? Da diese Form der goto-Fehlerbehandlung gerade in Unix-Kernels verwendet wird UND deren Übersetzung ein Standardbenchmark für jeden Compiler ist, haben die mit hoher Wahrscheinlichkeit darüber nachgedacht.

Weil ein Compiler nicht wirklich weiß, wo im Spagetthicode die Sprungmarke ist.
D.h. er findet sie zwar schon, aber eine Kenntnis über eine strukturierte Verschachtelung fehlt ihm völlig und mit diesem fehlenden Wissen kann er nur schlecht optimieren.

Das es Standardbenchmakrs für Compiler gibt ist klar, immerhin wird das für den Compiler sehr schwer, da noch etwas zu optimieren.
Die Standardbenchmarks zeigen also, dass gotos zu optimierproblemen führen.

Wenn ich meinen Compiler stattdessen mit einem ordentlich strukturierten Code füttere, so wie man es früher mit Pascal gelernt hat, dann weiß der wenigstens wo er optimieren kann und das macht er dann sehr gut.

Für den Compiler ist das goto ja nur ein weiterer Pfad... es gibt einmal den regulären Pfad, und dann welche mit goto. Der Compiler baut sich darauf seinen Ablaufgraph auf und optimiert entlang des Ausführungspfads.

Dem Ablaufgraph fehlt allerdings die Schachtelung, wenn der Programmierer sich mit den Gotos dumm angestellt hat.

[knivil]

Zeilenanzahl ist ungleich Komplexität, damit ohne Zusammenhang zur Fehleranfälligkeit.

Ich habe mal gehoert, dass Zeilenanzahl direkt proportional mit der Anzahl der Bugs korreliert. Das soll unabhaengig von Sprache, Programmierstil etc. Also etwa 100 Zeilen ein Bug. Siehe http://de.wikipedia.org/wiki/Fehlerquotient wobei ich in den Quellen nicht nachgelesen habe.

[icarus2]

Auch wenn goto grundsaetzlich gemiden werden sollte gibt es durchaus ein paar Ausnahmen, z.B.:
1. Um aus einer verschachtelten Schleife rauszuspringen (muss man wohl kaum erklaren unter welchen Umstaenden das wuenschenswert ist.
2. Nested Cleanup Code (wird zum Beispiel auch im Linux Kernel so gemacht).

@ Programmierfachprofi
Warum sollte ein Compiler strukturierten Code besser optimieren koennen als Code mit goto? Kannst du ein konkretes Beispiel geben bzw. etwas ausfuehrlicher sein?

*Edit
Auf http://www.systems.ethz.ch/courses/fall2012/SPCA in der 10. Vorlesung "Advanced C" gibts einen Abschnitt "goto" und dort gibts Beispiele zu Punkt 1 und 2.

[knivil]

Ich finde nicht, dass der Linuxkernel ein gutes Beispiel ist. Die meisten werden doch eher Anwendungssoftware schreiben, d.h. ist das Argument fehl am Platz.

1. Um aus einer verschachtelten Schleife rauszuspringen

Gar nicht erst verschachtelte Schleifen schreiben.

*Edit
Auf http://www.systems.ethz.ch/courses/fall2012/SPCA in der 10. Vorlesung "Advanced C" gibts einen Abschnitt "goto" und dort gibts Beispiele zu Punkt 1 und 2.

Und fuer Punkt 1.) wurde die Alternative gleich genannt und Punkt 2.) bezieht sich auf den Kernel.

[Bashar]

icarus2 schrieb:

@ Programmierfachprofi
Warum sollte ein Compiler strukturierten Code besser optimieren koennen als Code mit goto? Kannst du ein konkretes Beispiel geben bzw. etwas ausfuehrlicher sein?

Das Problem ist nicht goto per se, sondern ein irreduzibler Kontrollflussgraph. Damit funktionieren einige Optimierungsalgorithmen nicht. Mein Wissen reicht auf dem Gebiet aber nicht über Halbwissen hinaus, deshalb soll das an der Stelle genügen. Ein google-Stichwort hab ich ja gegeben.

[Marc++us]

Bashar schrieb:

sondern ein irreduzibler Kontrollflussgraph.

... aber der liegt in den hier gezeigten Beispielen doch kaum vor. Das ist ungefähr vergleichbar wie ein Switch-case.

[icarus2]

knivil schrieb:

Ich finde nicht, dass der Linuxkernel ein gutes Beispiel ist. Die meisten werden doch eher Anwendungssoftware schreiben, d.h. ist das Argument fehl am Platz.

Mein Punkt war nicht, dass jeder Verwendung dafuer findet sondern bloss, dass eine kategorische Ablehnung gegenueber goto nicht berechtigt ist.

knivil schrieb:

Gar nicht erst verschachtelte Schleifen schreiben.

Dass man in stinknormaler Anwendungssoftware keine verschachtelten Schleifen braucht kann ich noch glauben (ich weiss es nicht, denn ich habe leider noch nie als Softwareentwickler gearbeitet). Aber bei gewissen Algorithmen frage ich mich schon wie man da um verschachtelte Schleifen rumkommt.

Mir ist klar, dass die meisten Programmierer damit nie konfrontiert werden. Mein Punkt war bloss, dass in gewissen Bereichen goto durchaus Verwendung findet. Auch wenn die meisten das nie brauchen schadet es nicht das zu wissen.

@ Bashar:
Thx fuer das Stickwort. Werde mal danach googeln.

[Marc++us]

knivil schrieb:

Ich habe mal gehoert, dass Zeilenanzahl direkt proportional mit der Anzahl der Bugs korreliert.

Absolut gesehen ja.

Ich habe es hier auf das Beispiel von ihm bezogen, ich glaube ich habe eine Zeile mehr, weil ich für goto + Label eine Zeile mehr brauche als seine Lösung.

[knivil]

Mein Punkt war bloss, dass in gewissen Bereichen goto durchaus Verwendung findet.

Das zweifelt niemand an. Dennoch ist es in den meisten Faellen eine schlechte Idee.

[Marc++us]

knivil schrieb:

Ich finde nicht, dass der Linuxkernel ein gutes Beispiel ist.

Das Originalbeispiel war Anprogrammierung von Grafik... also typische Init-Exit-Sachen von Grafikstruktur hier, Port da, etc.

Die Masse der Leute hier wird ja hoffentlich die Anwendungen auch nicht in C schreiben...

[knivil]

Ich halte das ganze fuer einen Trollpost.

[assembl0r]

Marc++us schrieb:

Die Masse der Leute hier wird ja hoffentlich die Anwendungen auch nicht in C schreiben...

ach, die masse ...
richtige programmierer schreiben es in assembler

[Bitte ein Bit]

Ich habe mal gehoert, dass Zeilenanzahl direkt proportional mit der Anzahl der Bugs korreliert. Das soll unabhaengig von Sprache, Programmierstil etc. Also etwa 100 Zeilen ein Bug.

Das ist wohl der Grund warum einige Programmierer viel Code in eine Zeile packen...

if (a==0) {b=5;c=6;d=-1}
switch (a) {
  case 0: b=5;c=4;break;
}

:xmas1:

Alle unnötigen Leerzeichen entfernen und soviel wie möglich in eine Zeile packen s.d. man möglichst wenig LOC hat s.d. man möglichst wenig Fehler hat.

[SeppJ]

Theoretisch braucht man nirgendwo Zeilenumbrüche. Der Zeilenumbruch hat keine besondere Bedeutung in C (außer dass er auch ein Whitespace ist).

[cooky451]

Das werde ich ab jetzt ausnutzen, offenbar hilft es ja dabei Bugs zu vermeiden.

[Lotte89]

Thx an alle fuer den Tipp mit dem goto.
Das Kartenspiel ('Watten') ist jetzt 'so gut wie' fertig, einzig beim
'Verzoegern' der Animation scheint mir, dass ich nicht die optimale
Loesung hinkriege, weil ja der CPU Gegner so extrem schnell seine Spielzuege
berechnet, hab ich an mehreren Stellen die Ausfuehrung des Programms
mit 'Sleep()' verzoegert, damit der User mitkriegt, was vor sich geht.

Hier so eine Beispielfunktion:

/* Spezielle, verzoegernde Anzeige der durch HUM_PLR 'als erster' ausgespielten Karte */
static void drawHumPlr1st(void){
	HBRUSH oldBrush;
	HDC hdc;
	RECT *oldLoc, *centLoc, *bltSrc;
	/* 1. -> Mit Hintergrund-Farbe uebermalen: Bereich der ausgespielten Karte im Talon
		 2. -> ausgespielte Karte kurz 'solo' im Ausspiel-Bereich darstellen */
	hdc = GetDC(GodObject->hAppWnd);
	if(hdc){
		oldLoc = &GodObject->Player[HUM_PLR].TalonBlitDest[Move.AusCardIdx];
		centLoc = &GodObject->Player[HUM_PLR].playedBlit;
		bltSrc = GodObject->BlitSrc[GodObject->Player[HUM_PLR].Cards[Move.AusCardIdx]];

		oldBrush = SelectObject(hdc, GodObject->BackColor);
		PatBlt(hdc, oldLoc->left, oldLoc->top, STD_CARD_WIDTH, STD_CARD_HEIGHT, PATCOPY); /* ok 1. */
		BitBlt(hdc, centLoc->left, centLoc->top, STD_CARD_WIDTH, STD_CARD_HEIGHT,
			GodObject->hMemDC, bltSrc->left, bltSrc->top, SRCCOPY); /* ok 2. */

		Sleep(DELAY_SHORT); /* <-- ?? UM GENAU DIESE STELLE GEHT'S */

		SelectObject(hdc, oldBrush);
		ReleaseDC(GodObject->hAppWnd, hdc);
	}
}

Hier schlaeft das Programm z.B. fuer 500 ms (als #define so festgelegt),
damit der Spieler das 'Nacheinander' des Ausspielens der Karten ueberhaupt
mitkriegt.
Aber auch eine halbe Sekunde vergeht ja ziemlich flott.
Andererseits moechte man es dem User ersparen, dass er nach jeder Veraenderung
in der GUI noch zusaetzlich wo draufklicken muss, damit das Spiel fortgesetzt
wird.
Habe wo gelesen, dass man eine GUI-Anwendung normalerweise nicht gar zu
lange auf Sleep() schicken soll, weil sonst die Message Queue überquellen
könnte. Die Message-Queue räume ich zwar in regelmäßigen Abständen mit
PeekMessage() auf (das Programm schaltet ja auch ständig zwischen Warte-Modus
und Aktiv-Modus hin- und her).
Was wäre denn da eine gescheitere Lösung, um die Animation zu verzögern.
Das Programm läuft zwar auch mit dem Sleep() halbwegs zufriedenstellend und
so, wie geplant, aber vielleicht kennt ja wer von Euch eine 'elegantere'
Lösung für solche Animations-Verzögerungs-Aufgaben, wäre echt toll
wenn mir da nochmal jemand einen Tipp geben könnte !

Und nochmal thx für die Tipps wegen dem goto, hab jetzt alle goto's eliminiert!
Das ganze Programm ist halt ziemlich TopDown reingehämmert worden, aber
die Hauptsache ist ja, dass es halbwegs funktioniert.

mfg

[c89]

Hallo,

das muss ein Trollthread sein, erkennbar am GodObject.