Funktion mit mehreren Ausgängen

ja

Wobei der obige Quelltext auch kein Schmuckstück ist.

>Wobei der obige Quelltext auch kein Schmuckstück ist.
Und das machst du woran fest?
Ein switch/case würde hier nichts bringen, sind zwei verschiedene 
Variablen die abgefragt werden.

Nils S. schrieb:
>>Wobei der obige Quelltext auch kein Schmuckstück ist.
> Und das machst du woran fest?
> Ein switch/case würde hier nichts bringen, sind zwei verschiedene
> Variablen die abgefragt werden.

Nein, von switch habe ich hier nicht geträumt.
Was mich etwas daran stört, ist der Umstand, daß von den
drei returns genau eines ausgeführt wird; das drückt sich aber
nicht offensichtlich in der Struktur aus.
Wenn man mehrere formal unabhängige if hat, von denen aber
maximal eines erfüllt sein kann, dann erfordert das beim
Erfassen einen zusätzlichen Denkschritt.
Mit if - else if - else wird es dagegen klar ausgedrückt.

Deshalb fände ich etwas in dieser Art logischer:

1

int funktionXYZ(void)

2

{

3

   if(yxz)

4

   {

5

      return 0;

6

   }

7

   else if(abc)

8

   {

9

      return iVar;

10

   }

11

   else

12

   {

13

      return 12;

14

   }

15

}

Nur um die Nachfrage zu beantworten; eigentlich tut es hier nichts
zur Sache ist und ist auch nicht besonders relevant...

Ach, das ist wieder so eine Sache mit Theorie und Praxis.
Schau dir mal das an:

1

int foo(void) {

2

  int res = 0;

3

4

  res = a();

5

  if (!res) {

6

    res = b();

7

    if (!res) {

8

      res = c();

9

    }

10

  }

11

  return res;

12

}

Und dann das:

1

int foo(void) {

2

  int res = 0;

3

4

  res = a();

5

  if (res) return res;

6

7

  res = b();

8

  if (res) return res;

9

10

  res = c();

11

  return res;

Was ist nun wohl übersichtlicher? Auch bei mehrfach geschachtelten 
Schleifen oder switch()-Statements ist es ganz praktisch, wenn man im 
Fehlerfall direkt den Notausgang nehmen kann und sich nicht erst mit 
Flags und breaks durch alle Blöcke hangeln muss.
Bei Code, der z.B. Aufräumarbeiten erfordert ist es aber durchaus 
sinnvoll, nur ein Funktionsende zu haben.

Und was ist an MISRA so toll, außer daß einige Leute MISRA toll finden?

Wenn man sich mit einem scharfen Messer in den Finger schneiden kann,
essen wir die Kuh lieber in einem Stück.

Tom schrieb:
> Ja aber du hast auch 3 return leut der Aussage von meinen Lehrer darf
> man in einer Funktion max 1 return haben.

So weltfremden Unfug können nur Pauker abschwallen. Und daß es nichts 
nutzt, mit so einen Scholastiker zu diskutieren, ist selbstredend...

Wie andere schon geschrieben haben: Es kommt auf Übersichtlichkeit und 
leichte Durchschaubarkeit am.

Und den, der in der Praxis Struktogramme benutzt, den möchte ich 
sehen.

ich, aber nur gelegentlich zugegebenermaßen

Ob du mich sehen willst steht auf einem anderen Blatt :-)

Das ist wie mit "niemals goto": es ist etwas Wahres dran in den
meisten Fällen, aber mit Verstand verwendet ist es manchmal doch
besser.

Wie mit vielen Ideologien halt.

Ich oute mich bei dieser Gelegenheit: Vor drei oder vier Jahren
habe ich auch goto benutzt, und halte es nach wie vor für richtig...

Ich finde das mehrfache Return schon äußerst nützlich, weil ja leider 
die C-Erfinder das Break einer Schleife auch unbedingt für das Switch 
mißbrauchen mußten.
Daher gehen mehrere Abbruchbedingungen einer Schleife übersichtlich 
geschrieben nur mit Returns:

1

  for( u; v; w){

2

     //... code

3

     switch( x ){

4

       case a: return b;

5

       case c: return d;

6

       // ... usw.

7

     }

8

  }

Ich schließe mich daher an, Verstehbarkeit geht vor Dogmatismus.

Peter

Klaus Wachtler schrieb:
> Das ist wie mit "niemals goto": es ist etwas Wahres dran in den
> meisten Fällen, aber mit Verstand verwendet ist es manchmal doch
> besser.

Hast du schon mal versucht, aus einer inneren Schleife eine umschießende 
Schleife zu verlassen?

Ohne goto kommt ein entsetzlicher Krampf dabei raus.

Es gibt in C wenige, aber durchaus gute Gründe, goto zu benutzen

Nils schrieb:
> Neben Lesbarkeit gibt es noch einen Grund das return gezielt
> einzusetzen: Optimierung der Laufzeit.

Das glaube ich nun weniger. Heutige Optimizer sind clever genug, auch 
anders optimalen Code zu erzeugen - der hat nämlich keine Jump-Phobie 
und das Geschwätz von Paukern ist ihm sowieso wurscht...

Der Compiler macht immer sein eigenes Ding, egal wieviel Returns und an 
welcher Stelle.

Auch wenn Du nur ein Return im Code hast, aber mehrere 
Abbruchbedingungen, dann kann er mehrere Returns draus machen.

Und wenn Du mehrere Returns hast, aber lokale Variablen aufm Stack, dann 
springt er von allen an das einzige Return am Ende, wo der Stack 
aufgeräumt wird.


Peter

naja, ich bin kein Fan von 1000 versteckten return irgendwo.

Aber was ein C-Compiler im Extremfall können muß, und was als
elegantes Programmieren bezeichnet wird, ist nicht ganz deckungsgleich.

Da hast du recht. Es ist wie mit einem Küchenmesser: man kann ein tolles 
Menü damit zubereiten, oder die Schwiegermutter abstechen...

Eingesehen!
Das Menü wäre nur ein kurzfristiges Vergnügen.

Nils schrieb:
> Ok. Würdet Ihr soweit gehen zu sagen, dass solche Codeoptimierungen 'von
> Hand' bei heutigen C-Compilern nichts bringen?

Ja, so ist es. Die Compiler können das meist so gut, daß man selbst als 
Assemblerprogrammierer seine liebe Not hat, mitzuhalten. (Vom 
Zeitaufwand gar nicht zu reden.)

Allerdings ist das meistens nur eine lokale Optimierung innerhalb einer 
Funktion. Der entgehen natürlich Design-Dummheiten und genau da kann man 
als Programmierer durch gut durchdachte Struktur und vor allem 
effiziente Algorithmen sehr viel herausholen.