Ein goto zu einer bestimmten stelle

[TeXpert]

Wenn ich mich mal einmischen darf:

darfst Du und ich möchte Dir vollständig zustimmen, mit einer Einschränkung:

if (!InitDev1() || !InitDev2() || !InitDev3())

hier greifst Du implizit auf die reihenfolge zu, das ist AFAIR Compilerabhängig, ob hier short-evaluation stattfindet oder nicht. Wenn initdev2 nicht ausgeführt werden darf, wenn i1 fehlschlägt, muss das berücksichtig werden. aber das sind genau die 2% die Du auch erwähnst

 

[taki]

Wenn ich mich mal einmischen darf:

darfst Du und ich möchte Dir vollständig zustimmen, mit einer Einschränkung:

if (!InitDev1() || !InitDev2() || !InitDev3())

hier greifst Du implizit auf die reihenfolge zu, das ist AFAIR Compilerabhängig, ob hier short-evaluation stattfindet oder nicht. Wenn initdev2 nicht ausgeführt werden darf, wenn i1 fehlschlägt, muss das berücksichtig werden. aber das sind genau die 2% die Du auch erwähnst

...und die durch das zweite Beispiel (mit Exceptions) schon wieder überflüssig werden.

 

[TeXpert]

bei c++ ja, bei c nein

 

[SchodMC]

Wenn ich mich mal einmischen darf:

darfst Du und ich möchte Dir vollständig zustimmen, mit einer Einschränkung:

if (!InitDev1() || !InitDev2() || !InitDev3())

hier greifst Du implizit auf die reihenfolge zu, das ist AFAIR Compilerabhängig, ob hier short-evaluation stattfindet oder nicht. Wenn initdev2 nicht ausgeführt werden darf, wenn i1 fehlschlägt, muss das berücksichtig werden. aber das sind genau die 2% die Du auch erwähnst

Da hast Du nicht ganz unrecht, aber bei den meisten Kompilern wird von Links nach Rechts ausgewertet. Zumindest Trifft das bei den Handelsüblichen Kompilern für die Intel und AMD schiene zu (Borland, MS, Intel, GCC, ...).

Man sollte sich nicht darauf verlassen, das stimmt schon. Und wenn man sich schon darauf verlässt, muss man sich das Konstrukt genauestens anschauen! Aber eben darum gibt's ja exceptions um sowas dann anders erledigen zu können. Letztendlich finde ich, dass man sich enfach mal überlegen sollte, ob ein Code der mit goto realisiert wurde nicht auch anders zu regeln ist. Und in den meisten Fällen müsste das eben gehen.

Begonnen hat die Diskussion ja damit, dass mmp5 auf C umsteigen möchte. Da wäre es auf jeden Fall vernünftiger von Anfang an eine strukturierte Vorgehensweise zu lernen als gleich mit goto weiter zu machen. Ich wage es zu bezweifeln, dass er auf die 1-2 % trifft (z.B. Kernel Treiber wo keine Exceptions verfügbar sind) die goto notwendig machen!

 

[framp]

Exceptions sind eine feine Sache und gar nicht kompiziert!.

Ja, aber nur wenn es ein Exceptionkonzept im Entwicklerteam gibt. Ansonsten schmeisst ein jeder, wenn er Probleme hat ein Exception - und keiner kuemmert sich um Recovery oder wenigstens eine vernuenftige Fehlermeldung :roll: . Und der Dumme ist der Benutzer, der den Dump oder den Stacktrace interpretieren darf...

 

[TeXpert]

Und der Dumme ist der Benutzer, der den Dump oder den Stacktrace interpretieren darf...

und Dir ist ein Programm lieber dass wegen einem fehlgeschlagenen new absemmelt? das exceptions gecatched werden ist doch wohl klar...

 

[framp]

das exceptions gecatched werden ist doch wohl klar...

Vielleicht fuer Dich. Ich habe aber schon diversen Code (auch von gestandenen Programmierern) gesehen der so aussah:

   ...
    x = new y(...);
   ...

anstelle von

try {
   ...
    x = new y(...);
   ...
} catch (Exception ex1) {
 ... // handle exception und u.U rethrow ex1
 }

 

[TeXpert]

naja, wer sich auf ein funktionierendes new verlässt... nicht umsonst wirft new ein bad_alloc...

 

[Anonymous]

da gilt btw.

This is acctually a good idea, but I cant go along with it.. I'll PM you with my idea.