C-Programm ohne goto

die for schleife hat doch einen Wert z.B. i. Du kannst ja den Wert auf 
dein maximum setzen und bendest dann auch die for-schleife

sorry blödsinn :) vergesse es

1

ab=false;

2

for (Schleifenbedingung)

3

   {

4

    Befehl;

5

    Befehl;

6

    while (Bedingung)

7

       {

8

        Befehl;

9

        if (Abfrage) {

10

            ab = true;

11

            break;

12

        }

13

        if(ab) break;

14

        Befehl;

15

       }

16

   }

so sollte es gehen

eher nicht...

ich schrieb:
> eher nicht...

nicht?

if(ab) break;
Befehl;

natürlich in die for-schleife nicht in die while!

Wie wärs es in eine Unterfunktion zu packen?

1

void foo(void) {

2

 for (Schleifenbedingung) {

3

  Befehl;

4

  Befehl;

5

  while (Bedingung) {

6

   Befehl;

7

   if (Abfrage) return; //verlasse beide Schleifen

8

   Befehl;

9

  }

10

 }

11

 return;

12

}

Eventuell die Schleifenbedingung, Bedingung und Abfragewert als 
Parameter übergeben falls sie nicht global sind oder lokal gesetzt 
werden.

warum kein goto? einfache verschachtelte schleifen ohne goto sind in 80% 
der fälle wurstiger code mit redundanzen.

Kermit schreibt:
>Warum kein goto?

Goto ist verpönt, da man damit
sehr unübersichtlichen Programmcode
erzeugen kann (Spagetti-Programmierung).
In JAVA gibt es z.B. gar kein goto mehr.

Ich werde aber hier doch ein goto nehmen,
und das Sprungziel direkt unter die Schleifen
setzten. Das scheint mir gut lesbar zu sein.

Danke an alle für die Tipps!

> Gibt es eine Lösung ohne goto ;-)

1

void f()

2

{

3

for (Schleifenbedingung)

4

   {

5

    Befehl;

6

    Befehl;

7

    while (Bedingung)

8

       {

9

        Befehl;

10

        if (Abfrage) return; //verlasse beide Schleifen

11

        Befehl;

12

       }

13

   }

14

15

}

?

ich wette, dass 10k mal öfter gesagt wird goto ist scheiße, als 
verkackter code mit goto gelesen wird.

oder:

ich wette, dass 99% der leute, die sagen goto ist verpönt, noch nie 
verkackten goto-code gesehen haben.

1

#define gehezu goto

und schon ist das goto weg ;-)

wenn es passt und den code leserlicher gestaltet, verwende es.
weenn es dein code ist - mach was du willst, wenn dir dein arbeitgeber 
ein goto verbieten möchte/verbietet hast du zwei möglichkeiten:
- gut argumentieren und eine rebellion veranstalten
- akzeptieren und hässliche/schlecht lesbare/sonstige workarounds 
einbauen...

Peter Dannegger schrieb:
> Die mit Return kostet etwas Stack, ist aber gleich gut leserlich, wie
> das Goto. Und dann kommen aber die Nörgler, die sagen, daß jede Funktion
> nur ein Return haben soll.

Jepp, und die Nörgler haben oft recht. Wie toll ist es wenn Du am Ende 
einer Funktion einen Breakpoint setzen willst und musst dann 2 oder 3 
oder 7 setzen, weil entsprechend viele returns da sind.
Wie toll ist es wenn du am Ende der Funktion schnell einen Trace 
rausschreiben willst und kannst auch das dann 3 oder gar 7 mal machen.

Peter Dannegger schrieb:
> Die mit ner Variable macht den Code deutlich unleserlicher und kann
> sogar richtig teuer werden, wenn extra für diese zusätzliche Variable
> ein Stackframe angelegt werden muß.

Der Code von Markus war keinen Deut schlechter. In Sachen Effizienz gabe 
ich dir 100% recht, wobei das auf µCs manchmal eine Rolle spielt, auf 
PCs nur in absoluten Ausnahmefällen.

Peter Dannegger schrieb:
> Man sollte Goto nicht unnütz nehmen. Wenn es aber paßt, wie die Faust
> aufs Auge, dann nimmt man es einfach.
>
> Irgendwelche Dogmen auszusprechen und sich sklavisch daran
> festzukrallen, halte ich für Schwachsinn. Der gesunde Menschenverstand
> sollte Vorrang haben.

100% agree, deshalb habe ich oben auch nur oft gesagt :-)

benjamin tülpchen schrieb:
> ich wette, dass 99% der leute, die sagen goto ist verpönt, noch nie
> verkackten goto-code gesehen haben.

Ich habe mal ein paar Jahre Code warten müssen, der von einem 
selbstgeschriebenen Cross-Compiler (nicht von mir) aus IBM-Host 
Assembler C für Unixsysteme und Windows und OS/2 erzeugt hat. So grausam 
kann kein Mensch C Spagetticode programmieren, nicht mal einer der sonst 
nur Basic programmiert hat :-).

Gruß

Ein "goto" ist wie Gift, genauso wie vieles gute in Medizin. Es gibt
Programme die dankt dem Befehl gut strukturiert und gut lesbar sind.
Z.B. am Anfang prüft man die Plausibilität von sehr vielen Angaben. Wenn 
etwas nicht passt dann lädt man Puffer für Anzeige eine Meldung und mit 
einem Sprung „goto Ergebnis“ verlässt man egal wie tief verschaltete 
Schleife. Im Ergebnis prüft man dann ob etwas zum Schlissen (geöffnete 
Files) oder zum Freigeben (Speicher).

U.R. Schmitt schrieb:
> Peter Dannegger schrieb:
>> Die mit Return kostet etwas Stack, ist aber gleich gut leserlich, wie
>> das Goto. Und dann kommen aber die Nörgler, die sagen, daß jede Funktion
>> nur ein Return haben soll.
>
> Jepp, und die Nörgler haben oft recht. Wie toll ist es wenn Du am Ende
> einer Funktion einen Breakpoint setzen willst und musst dann 2 oder 3
> oder 7 setzen, weil entsprechend viele returns da sind.
> Wie toll ist es wenn du am Ende der Funktion schnell einen Trace
> rausschreiben willst und kannst auch das dann 3 oder gar 7 mal machen.

Da lässt sich aber drüber streiten. Man kann eine Funktion auch ganz 
schön unübersichtlich machen, wenn man aus Krampf nur ein return haben 
möchte. Das gibt dann auch gerne Spaghetticode. Der Königsweg wäre 
natürlich, per goto zu einem Return zu springen ;-)

Nico

Nico22 schrieb:
> Da lässt sich aber drüber streiten. Man kann eine Funktion auch ganz
> schön unübersichtlich machen, wenn man aus Krampf nur ein return haben
> möchte. Das gibt dann auch gerne Spaghetticode.

Jepp, ganz klar, wie Peter gesagt hat:
> Irgendwelche Dogmen auszusprechen und sich sklavisch daran
> festzukrallen, halte ich für Schwachsinn. Der gesunde Menschenverstand
> sollte Vorrang haben.

> Königsweg wäre natürlich, per goto zu einem Return zu springen ;-)
***ROFL***

Das ist in java toll. Du klammerst das mit einem try finally und kannst 
dort dann alles sauber beenden, egal wie verschachtelt das Ganze ist.
Das ist nämlich das nächste Problem mit mehreren returns. Du hast eine 
komplexere Aktion, z.B: liest Du aus einer Datei/Dateien und/oder 
MQ-Queues Daten und speicherst Sie (abhängig von dem was Du gelesen 
hast, also komplexe Bedingungen und ggf. Schleifen) in eine Datenbank 
und oder andere Queues. Am Ende musst Du alles aufräumen und je nachdem 
ob es geklappt hat in MQ und Datenbank commit oder rollback absetzen. 
Dann noch mehrere Returns und deine Funktion/Methode wird nie richtig 
funktionieren.
Mit try finally problemlos in den Griiff zu kriegen.

Aber Java in µCs ist auch nicht meine Präferenz :-)

Oh ja, finally fehlt mir in C++.

U.R. Schmitt schrieb:
>> Königsweg wäre natürlich, per goto zu einem Return zu springen ;-)
> ***ROFL***
>
> Das ist in java toll. Du klammerst das mit einem try finally und kannst
> dort dann alles sauber beenden, egal wie verschachtelt das Ganze ist.

Solange dich nicht interessiert, wo innerhalb des Blocks die Exception 
aufgetreten ist. Sonst mußt du halt um jede Funkton ein eigenes try 
setzen.

> Das ist nämlich das nächste Problem mit mehreren returns. Du hast eine
> komplexere Aktion, z.B: liest Du aus einer Datei/Dateien und/oder
> MQ-Queues Daten und speicherst Sie (abhängig von dem was Du gelesen
> hast, also komplexe Bedingungen und ggf. Schleifen) in eine Datenbank
> und oder andere Queues. Am Ende musst Du alles aufräumen und je nachdem
> ob es geklappt hat in MQ und Datenbank commit oder rollback absetzen.
> Dann noch mehrere Returns und deine Funktion/Methode wird nie richtig
> funktionieren.
> Mit try finally problemlos in den Griiff zu kriegen.

Mit goto auch.

> Oh ja, finally fehlt mir in C++.

Warum? Dank vernünfig funktionierender Destruktoren braucht man das doch 
gar nicht.

Nur nicht-Informatiker können über so eine Lapallie so lange Diskutieren 
:D

qt schrieb:
> Nur nicht-Informatiker können über so eine Lapallie so lange Diskutieren

Stimmt, Informatiker schreiben darüber eine Doktorarbeit :-P

Klaus Wachtler schrieb:
> naja, manchmal wäre es schon nett.
> Wenigstens das finally kann man Java als Vorteil zugestehen.

Ich sehe es eher als Krücke, die man eingebaut hat, weil die 
Destruktoren fehlen.

Klaus Wachtler schrieb:
> ok, daß der Grund für finally in Java ein übler ist, macht
> den Mechanismus ja nicht per se schlecht.

Genau darum ging es mir. Wenn man nicht Lust hat, jedes 
C-init()-und-end() in eine eigene Klasse zu kapseln (was natürlich sehr 
elegant ist), dann vermisst man das finally manchmal schon. Es geht 
natürlich auch ohne.

Gruß,
Nico

Stimmt, einen GC vermisse ich auch überhaupt nicht. Ist aber immer 
schon, wenn einem valgrind zeigt, dass man doch lieber RAII hätte 
benutzen sollen, weil man irgendwo ein *_end() vergessen hat.

Rolf Magnus schrieb:
> Ich sehe es eher als Krücke, die man eingebaut hat, weil die
> Destruktoren fehlen.

Sorry aber das ist ziemlicher Blödsinn.
Mit finally kann man auch innerhalb einer Methode viel feiner granuliert 
Dinge 'zum lokalen' Schluß beenden.
Und komm mir nicht mit OO-Designtheorien daß dann das Design falsch ist 
und man einzelne Klassen mit jeweils einem Destruktor machen müsste.
Man kann den Spiess auch umdrehen und sagen, C++ hat die Destruktor 
Krücke weil ...
Ausserdem wollte ich hier keine "die Programmiersprache ist besser 
weil..." Diskussion lostreten.
Aber es fühlen sich manche immer wieder ans Bein gepinkelt, wenn man 
"Ihr" System, Sprache, Tool angeblich schlecht macht, nur weil man wagt 
darauf hinzuweisen, daß es bei einem anderen Tool, System, Sprache, ... 
andere Konzepte gibt.
Viel Spass

@Detlev T.:

ja, so ähnliche mache ich das auch. Wenn man gute Bezeichner wählt, ist 
es übersichtlich und logisch. Evtl. ein klein wenig ineffizienter als 
andere Lösungen, aber schön.


@Markus:

>for (i=0; (i<4)&&(!abbruch); i++)

Hmmm, gefällt mir nicht sooo gut. for-Schleifen verwende ich nur, wenn 
die Abbruchbedingung feststeht (z.B. Anzahl der Elemente eines Arrays 
etc.)
Sonst verwende ich lieber eine while- oder do-while-Schleife.