c: Wie multiple return-Statements vermeiden?

Mike schrieb:
> Nun gelten mehrfache returns bekanntlich als schlechter Programmierstil.
> Wie kann man das vermeiden, ohne an Übersichtlichkeit zu verlieren? Eine

 Vielleicht auf Null abfragen, anstatt auf != 0.

Mike schrieb:
> Nun gelten mehrfache returns bekanntlich als schlechter Programmierstil.

Das ist sicher keine allgemeingültige Meinung.

Mike schrieb:
> Wie kann man das vermeiden, ohne an Übersichtlichkeit zu verlieren?

Schwierig, viel übersichtlicher wird es nicht werden, und das ist eines 
der wichtigen Ziele in der Programmierung.

Mike schrieb:
> Eine
> Unzahl von verschachtelten if/else Abfragen mit entsprechend vielen
> geschweiften Klammern ist meiner Meinung nach keine Alternative.

Du könntest über die Möglichkeiten loopen.

Ein array von funktionspointern übergeben und durch das array mit einer 
for schleife. Dann gibt es nur einen ausstiegspunkt (mit break oder auch 
mit return)

Alternativer Ansatz:

1

unsigned int check()

2

{

3

  unsigned int result = 0;

4

5

  result = func1();

6

7

  if (!result)

8

    result = func2();

9

10

  if (!result)

11

    result = func3();

12

13

  ... // viele weitere

14

15

  return result;

16

}

Allerdings sehe ich die Annahme "Nun gelten mehrfache returns 
bekanntlich als schlechter Programmierstil" als durchaus zwiespältig an.

Bestimmte Konstrukte sind mit mehrfachen Returns klar, kurz und 
übersichtlich.

Manche Konstrukte werden durch krampfhaftes Vermeiden mehrfacher Returns 
sogar ausgesprochen unübersichtlich.

1

unsigned int check()

2

{

3

  unsigned int result;

4

5

  if ((result = func1()) == 0 &&

6

      (result = func2()) == 0 &&

7

      (result = func3()) == 0)

8

  {

9

    result = do_something ();

10

  }

11

  return result;

12

}

Vorteile:
- Keine verschachtelten if-Statements
- Die Bedingungen stehen übersichtlich untereinander
- Die Reihenfolge der func()-Aurufe ist wie gewünscht
- Abbruch der func()-Aufrufe, sobald ein Fehler zurückkommt
- Keine Klammer-Orgie
- Nur ein return

Mike schrieb:
> Nun gelten mehrfache returns bekanntlich als schlechter Programmierstil.

Nö. Les mal Clean Code von Robert C. Martin.

Ist das C-Code oder C++? Im letzteren Fall
kann ich mir eine Lösung mit dem Decorator
Pattern vorstellen.

merciless

Mike schrieb:
> Nun gelten mehrfache returns bekanntlich als schlechter Programmierstil.
> Wie kann man das vermeiden,

Lass es so. Diese Regel wirkt sich nur aus wenn die unterschiedlichen 
returns irgendwo kreuz und quer in verschachtelten Schleifen stecken und 
es mühsam wird zu erkennen ob und wann der Teil darunter nun ausgeführt 
wird weil man sie übersehen kann oder weil sie an Bedingungen geknüpft 
sind für die man sich erstmal das Hirn verrenken muss um sie im Kopf 
durchzugehen.

Bei Deinem Beispiel sieht man auf den ersten Blick was da vor sich geht, 
da ist nichts versteckt oder überraschend, das vorzeitige Return ist das 
Kernthema und der Dreh- und Angelpunkt dieser Funktion, es springt einem 
sofort ins Auge und man kann es nicht übersehen. Also lass es so.

Frank M. schrieb:
> unsigned int check()
> {
>   unsigned int result;
>
>   if ((result = func1()) == 0 &&
>       (result = func2()) == 0 &&
>       (result = func3()) == 0)
>   {
>     result = do_something ();
>   }
>   return result;
> }
>
> Vorteile:
> - Keine verschachtelten if-Statements
> - Die Bedingungen stehen übersichtlich untereinander
> - Die Reihenfolge der func()-Aurufe ist wie gewünscht
> - Abbruch der func()-Aufrufe, sobald ein Fehler zurückkommt
> - Keine Klammer-Orgie
> - Nur ein return

Ich finde es fürchterlich, weil ich eine Zuweisung innerhalb einer 
Abfrage für sowas wie das Ausnützen eines Seiteneffekts halte. Beim 
flüchtigen Schnell-drüber-lesen ist die Zuweisung ratzfatz überlesen. 
Schlimmer noch: ein Nachfolgeprogrammierer könnte die Zuweisung sogar 
für einen Flüchtigkeitsfehler halten und ihn "korrigieren" wollen. 
Hirnknötchen völlig ohne Not, da wären multiple returns ganz sicher 
vorzuziehen.

Normalerweise quittieren viele Compiler Zuweisungen innerhalb einer 
Condition direkt mit einer Warnung.

Thomas M. schrieb:
> Ich finde es fürchterlich, weil ich eine Zuweisung innerhalb einer
> Abfrage für sowas wie das Ausnützen eines Seiteneffekts halte.

Darüber kann man geteilter Meinung sein.

> Beim
> flüchtigen Schnell-drüber-lesen ist die Zuweisung ratzfatz überlesen.

Dann machst du was falsch.

> Schlimmer noch: ein Nachfolgeprogrammierer könnte die Zuweisung sogar
> für einen Flüchtigkeitsfehler halten und ihn "korrigieren" wollen.

Dann ist es kein C-Programmierer.

> Hirnknötchen völlig ohne Not, da wären multiple returns ganz sicher
> vorzuziehen.

Die Reihe der normalen If() ist die saubere Variante, auch für 
empfindliche Gemüter.

Beitrag "Re: c: Wie multiple return-Statements vermeiden?"

> Normalerweise quittieren viele Compiler Zuweisungen innerhalb einer
> Condition direkt mit einer Warnung.

Dann sind es aber keine C-Compiler.

DPA schrieb:
> Warnung: alles ungetestet.
>
> Haben die Funktionen alle das gleiche Interface? Dann könntest du
> eventuell eine Schleife nehmen:
>

1

 wilder Code Wust

Das ist bestimmt eine nette Programmiersportaufgabe. Aber alleine dass 
ich beim Eingangspost mit einem Blick erkannte, was er wollte und diesen 
Codewust  direkt als tldr; abtat, sagt aus, dass diese Lösung unterlegen 
ist.


P.s.: tldr; = to long, didn't read

Thomas M. schrieb:
> Ich finde es fürchterlich, weil ich eine Zuweisung innerhalb einer
> Abfrage für sowas wie das Ausnützen eines Seiteneffekts halte.

Das ist ganz normales C. Wenn ich mich recht erinnere, lernt man das bei 
K&R direkt in Kapitel 1:

1

  while ((c = getchar ()) != EOF)

2

  {

3

    putchar (c);

4

  }

Wenn das schon die grauen Hirnzellen überfordert, sollte man es mit C 
besser sein lassen.

> Normalerweise quittieren viele Compiler Zuweisungen innerhalb einer
> Condition direkt mit einer Warnung.

Ja, wenn Du die Klammern um die Zuweisung vergisst - und das zu recht. 
Die habe ich aber nicht vergessen. ;-)

Arduino Fanboy D. schrieb:
> Es gibt ja auch noch Goto.

Naja - wer schon multiple returns verpönt, was sagt der wohl zum Thema 
goto?

In diesem Kontext (ohne weitere Berechnungen vor dem returm am 
Funktionsende) wäre goto return ja effektiv das selbe wie return, nur 
halt mit anderen Buchstaben geschrieben geschrieben und der werte Leser 
müsste noch Mausrad und Hirn beanspruchen, um das rauszukriegen.

DPA schrieb:
> Falk B. schrieb:
>> Dann sind es aber keine C-Compiler.
>
> gcc und clang können das.

Du hast Falk missverstanden.

Er meinte: Wenn ein C-Compiler das anmeckert, was ich anständig in

1

(result = func1()) == 0

geklammert habe, dann ist es kein C-Compiler. Und da hat Falk vollkommen 
recht.

Thomas M. schrieb das nämlich zu allgemeingültig. Er behauptete, dass 
einige C-Compiler immer bei Zuweisungen innerhalb eines Vergleichs 
meckern. Das stimmt aber nicht. Klammert man sorgfältig, ist das 
vollkommen okay und kein C-Compiler der Welt meckert das an.

DPA schrieb:
> Das erste beispiel ist nur 15 Zeilen lang, also weniger als das
> Original.

1

typedef unsigned int (*check_function)(void);

2

3

const check_function check_list[] = {

4

  check_1,

5

  check_2,

6

  check_3,

7

  0

8

};

9

10

unsigned int check(void){

11

  unsigned int result = 0;

12

  for(check_function* f=check_list; *f && !result; f++)

13

    result = f();

14

  return result;

15

}

Ehrlich gesagt ... ab einer ausreichend großen Anzahl von check_n 
Funktionen  würde ich es wohl ziemlich genau so machen. :)

Bei n <= 3 würde ich es jedoch ausgerollt lassen.

Ich würde es so machen - das ist aus meiner Sicht lesbar(er):

1

unsigned int check()

2

{

3

  unsigned int result;

4

5

  if( ( result = func1() ) == 0)

6

    if( ( result = func2() ) == 0)

7

      if( ( result = func3() ) == 0)

8

  ... // viele weitere

9

        return 0;

10

11

  return result;

12

}

Rufus Τ. F. schrieb:
> Manche Konstrukte werden durch krampfhaftes Vermeiden mehrfacher Returns
> sogar ausgesprochen unübersichtlich.

Haste grade MISRA gesagt?

Mw E. schrieb:
> Haste grade MISRA gesagt?

Die Kernaussage, warum man vorzeitige Returns in der Regel vermeiden 
sollte:

Werden am Ende der Funktion noch Aufräumaktionen getätigt, läuft man 
Gefahr, diese bei vorzeitigen Returns einfach zu vergessen.

Eine Folge könnten zum Beispiel die allseits bekannten Memory-Leaks 
sein. Existiert jedoch keine solche Aufräumaktion, habe ich auch keine 
Skrupel, ein vorzeitiges Return einzubauen.

Johann J. schrieb:
> ... // viele weitere

So ab 70 wirds mit den Einrückungen aber etwas unschön ;)

Ich finde das Original ja nach wie vor gut, aber bitte, einen hab ich 
auch noch:

1

  if ((result = func1()) !=0) return result;

2

  if ((result = func2()) !=0) return result;

3

  if ((result = func3()) !=0) return result;

4

  if ((result = func4()) !=0) return result;

Oliver

Frank M. schrieb:
> Thomas M. schrieb das nämlich zu allgemeingültig. Er behauptete, dass
> einige C-Compiler immer bei Zuweisungen innerhalb eines Vergleichs
> meckern. Das stimmt aber nicht. Klammert man sorgfältig, ist das
> vollkommen okay und kein C-Compiler der Welt meckert das an.

Das mag sein. Aber das ist dann doch auch schon wieder irgendein 
Expertenklugsch***erwissen, von dem ich wetten würde, dass, wenn man mit 
einer Umfrage - selbst routiniertere und gute - Programmierer damit 
konfrontieren würde, es sich herausstellen würde, dass sie es auch nicht 
wussten.


Guter Stoff für eine Klausurfrage, aber im täglichen Einsatz so nutzlos 
wie Schachtelsätze.

Frank M. schrieb:
> Werden am Ende der Funktion noch Aufräumaktionen getätigt, läuft man
> Gefahr, diese bei vorzeitigen Returns einfach zu vergessen.

Genau. Und diesen Zustand umschifft man stilgerecht mit goto anstelle 
von return ;-)

Oder man baut ne ne dummy-Schleife und verlässt sie mit break.

Thomas M. schrieb:
> Das mag sein.

Das ist so. Zumindest sollte man den Basis-C-Standard verstanden 
haben.

> Aber das ist dann doch auch schon wieder irgendein
> Expertenklugsch***erwissen,

Wenn schon die C-Bibel von Kernighan & Ritchie als zweites 
Programmierbeispiel

1

  while ((c = getchar()) != EOF)

direkt nach dem Hello-World-Programm aufführt, dann sind das 
Anfänger-Basics und keinesfalls "Expertenklugsch***erwissen", wie Du 
es ausdrückt.

> Guter Stoff für eine Klausurfrage, aber im täglichen Einsatz so nutzlos
> wie Schachtelsätze.

Das ist im täglichen Einsatz. Und Du wirst diese Zuweisungen auch in 
fast jedem Open-Source finden, die etwas größer sind als Dreizeiler.

Bernd K. schrieb:
> Genau. Und diesen Zustand umschifft man stilgerecht mit goto anstelle
> von return ;-)

Hier ein Beispiel aus der Praxis:

  Beitrag "Re: [STM32/HAL] generischer Treiber für die beliebten I²C-Text-Displays"

Zunächst siehst Du da die goto-Orgie, wie W.S. das umgesetzt hat und 
dann von mir die Lösung ohne goto.

Welche ist lesbarer?

Frank M. schrieb:
> if ((result = func1()) == 0 &&
>       (result = func2()) == 0 &&
>       (result = func3()) == 0)
>   {

&& ?

ich weiss nicht, was all die function pointer orgien hier sollen ...
simple und kurz gehts auch!


uint_t check() {
  uint_t result;

  if (result=func1() || result=func2() || result=func2()) return result;

  return 0;
}


mt

Oliver S. schrieb:
> So ab 70 wirds mit den Einrückungen aber etwas unschön ;)

Noch nie was von "ordentlichen Bildschirmgrößen" gehört?  :-)

Bei solchen Schachtelungstiefen mit 7465 Checks würde ich dann eher so 
vorgehen (dann kann man check() auch gleich weglassen):

1

unsigned int func1()

2

{

3

  unsigned int result;

4

5

  // Schwieriger Check - Ergebnis in result 

6

7

  if( result == 0)

8

    result = func2();

9

10

 return result;

11

}

12

13

unsigned int func2()

14

{

15

  unsigned int result;

16

17

  // Schwieriger Check - Ergebnis in result 

18

19

  if( result == 0)

20

    result = func3();

21

22

 return result;

23

}

24

25

... func3, func4, ..., func7464, 

26

27

unsigned int func7465()

28

{

29

  unsigned int result;

30

31

  // Schwieriger Check - Ergebnis in result 

32

33

  return result;

34

}

35

36

37

unsigned int check()

38

{

39

  unsigned int result;

40

41

  result = func1();

42

43

  return result;

44

}

Stefanus F. schrieb:
> Und prompt einen Stack-Überlauf bekommen.

Wurde hier eine konkrete Architektur angesprochen?

Stefanus F. schrieb:
> Hmm, wer hat da wohl von wem abgeguckt. Sieht ja fast so aus, wie mein
> Beispiel.

Ich weiß nicht, was Du jetzt andeuten willst.

Ich habe lediglich den Code von W.S. konkret in dem genannten Beitrag 
rausgepickt und ad hoc umgeschrieben. Selbst verwende ich weder diesen 
Code noch Deinen. Mein I2C-Code, den ich für STM32 verwende und unter 
GPL veröffentlicht ist, sieht gänzlich anders aus.

Stefanus F. schrieb:
> Ich glaube das ist das einzige Szenario,

und das goto zur fehlerbehandlung ist im professionellen umfeld häufig 
bis standard. also goto ist kein teufelszeug!

es gibt noch viele andere "tricks" z.b. die verwendung von "!!" 
(negation der negation).

schon mal gesehen und den sinn in c verstanden?



mt

Apollo M. schrieb:
> es gibt noch viele andere "tricks" z.b. die verwendung von "!!"
> (negation der negation).

Sollte den aufmerksamen Lesern von µC.net allseits bekannt sein. Peter 
D. verwendet das sehr gern, um Werte auf 0 und 1 zu "normieren".

Arduino Fanboy D. schrieb:
> Switch/case ist da nicht unbedingt so effektiv.

wie leicht man doch getäuscht wird ...

switch/case ist nichts anderes als goto in einem anderen gewand


mt

wolpino schrieb:
> Mit dem guten alten do-while(0) Trick kann man es so machen:

Woraus man lernt, dass ein "break" auch nichts anderes als ein goto ist 
;-)

Ja, man sollte goto generell nicht verteufeln. Aber man muss es nicht so 
extensiv wie ein Old-School-Basic-Programmierer einsetzen.

Frank M. schrieb:
> Sollte den aufmerksamen Lesern von µC.net allseits bekannt sein. Peter
> D. verwendet das sehr gern, um Werte auf 0 und 1 zu "normieren".

korrekt! ich bin dann wohl ein spätzünder, weil erst spät realisiert.

ich denke, wir könnten mal breiter über clevere implementation tricks 
reden ... das würde sich lohnen!


mt

Thomas M. schrieb:
> Frank M. schrieb:
>> unsigned int check()
>> {
>>   unsigned int result;
>>
>>   if ((result = func1()) == 0 &&
>>       (result = func2()) == 0 &&
>>       (result = func3()) == 0)
>>   {
>>     result = do_something ();
>>   }
>>   return result;
>> }
>>
>> Vorteile:
>> - Keine verschachtelten if-Statements
>> - Die Bedingungen stehen übersichtlich untereinander
>> - Die Reihenfolge der func()-Aurufe ist wie gewünscht
>> - Abbruch der func()-Aufrufe, sobald ein Fehler zurückkommt
>> - Keine Klammer-Orgie
>> - Nur ein return
>
> Ich finde es fürchterlich, weil ich eine Zuweisung innerhalb einer
> Abfrage für sowas wie das Ausnützen eines Seiteneffekts halte. Beim

Solche Konstrukte sind eher Sache der Gewohnheit.  Bei den meisten 
Programmen sind Abfragen sehr einfach und der bedingte Code 
komplizierter.  Bei komplexen Aufgaben kann aber auch oft der umgekehrte 
Fall auftreten, sehr komplexe Bedingungen und simple (oder komplexe) 
Aktion.  Oft sind von der Bedingung Werte einzusammeln, ähnlich wie beim 
Pattern-Matching, wo, wenn ein Pattern passt, dieses eingesammelt und 
dann bedingt fortgefahren wird (unter verwendung des gematchten Texts).


> flüchtigen Schnell-drüber-lesen ist die Zuweisung ratzfatz überlesen.

Ist wie gesagt Gewohnheit, auch aufmerksames Lesen bzw. sinnvolle 
Commentare zu schreiben... Und man kann das Konstrukt auch außerhal 
einer Bedinung verwenden:

1

(void)

2

    (result = func1()

3

     || result = func2()

4

     || result = func3()

5

     ...

6

     || result = funcN());

7

8

if (result)

9

   return result;

Hier wird Shortcut-Evaluation benutzt, d.h. die Auswertung des || 
Ausdrucks erfolgt von links nach rechts und wird beendet, sobald result 
!= 0 ist.


> Normalerweise quittieren viele Compiler Zuweisungen innerhalb einer
> Condition direkt mit einer Warnung.

GCC gibt eine Warnung, allerdings nicht wenn die Zuweisung in Klammern 
steht, weshalb Frank die Zuweisungen klammerte.

wolpino schrieb:
> Mit dem guten alten do-while(0) Trick kann man es so machen:

gefälltt mir! kannte ich nur im kontext mit makros


mt

Johann L. schrieb:
> Shortcut-Evaluation

... ist sehr nützlich und mächtig, NUR scheuen die hobby/basic jünger 
dieses konstrukt wie das feuer genau so wie z.b.

switch(c=f())
witch(c=f() && ..)
if(c=f() && b=f2() || ...)

hier mal ein beispiel aus der macro ecke zu short-eval alias k-logic

//creates an unique timer for each instance, x: repeats 1-255
#define XPERIODIC(tb, dt, t, x)                 \
  static dt UNIQUE(tmr) = (dt) tb;              \
  static uint8_t UNIQUE(xRepeats) = x;          \
  if ((tb - UNIQUE(tmr) >= t)                   \
  && UNIQUE(xRepeats)                           \
  && (UNIQUE(xRepeats)--, UNIQUE(tmr) = tb, 1)) //UNIQUE(tmr) += t, 1))


mt

Ja im Falle dass man Aufräumaktionen machen muss würde ich sogar ein 
goto befürworten.

Sprachfeatures sind in aller Regel nicht an sich gut oder böse, es liegt 
am Programmierer sie sinnvoll und mit Bedacht anzuwenden.

Auch so was wie der "Destruktive Zuweisungsoperator" (= in C) kann für 
absolut furchtbaren Code sorgen. (Deshalb haben den viele Sprachen auch 
gar nicht drin)

Ich würde es ja sowieso in C++ machen, und da geht es dann elegant ohne 
goto und mehrfachen returns mit throw/catch ;)

Oliver

Apollo M. schrieb:
> if(c=f() && b=f2() || ...)

Da garantiert Dir übrigens keiner in welcher Reihenfolge die Funktionen 
ausgeführt werden. Manche Programmierer nehmen da einfach zum Beispiel 
an, dass die von rechts nach links abgearbeitet wird, was aber nicht 
immer der Fall ist.

Das Ergebnis von sowas sind dann "Heisenbugs". Fehler die im Livesystem 
auftreten, im Debuger jedoch nicht, sowie Code der abhängig von der 
Optimierungsstufe unterschiedliche Dinge tut.

Christian B. schrieb:
> Da garantiert Dir übrigens keiner in welcher Reihenfolge

darum gilt es dann diese variante zu verwenden

if(c=f(), c && b=f2(), b || ...)


dann sollte es passen!?



mt

Jemand schrieb:
> && und || garantieren Links-nach-Rechts Auswertung ihrer Operanden
> mit Sequenzpunkten.

so ist es! die zweite variante kann vielleicht die lesbarkeit verbessern 
und sonst nichts.

Schade, dass in C die Ergebnisse der && und ||-Operationen auf 0 und 1
beschränkt sind. In Python, wo dies nicht der Fall ist, kann man bspw.
folgendes schreiben:

1

def func1():

2

  print('func1')

3

  return 0  # ok

4

5

def func2():

6

  print('func2')

7

  return 0  # ok

8

9

def func3():

10

  print('func3')

11

  return 13  # fail

12

13

def func4():

14

  print('func4')

15

  return 0  # ok

16

17

18

def check():

19

  result = ( func1() or

20

             func2() or

21

             func3() or

22

             func4()    )

23

24

  if result == 0:

25

    print('do something')

26

27

  return result

28

29

30

result = check()

31

print('result:', result)

Ausgabe:

1

func1

2

func2

3

func3

4

result: 13

https://docs.python.org/3/reference/expressions.html#boolean-operations

leo schrieb:
> Das ist falsch, wegen Operator Precedence (result = func1() || result
> ...)

klammern, dann geht es!

if ((result = func1()) || (result = func2()) || (result = func3()))
...

mt

Das Beispiel selbst is eigentlich komplett funktional und schreit 
förmlich Monade. Das is in C halt leider eher häßlich und "short 
curcuit"-en tuts auch nicht.

1

#include <assert.h>

2

#include <stddef.h>

3

#include <stdio.h>

4

#include <stdlib.h>

5

6

struct Optional;

7

8

typedef unsigned int (*Fp)();

9

typedef struct Optional* (*AT)(struct Optional*, Fp);

10

11

typedef struct Optional {

12

  AT and_then;

13

  unsigned int result;

14

} optional_t;

15

16

optional_t* and_then(optional_t* o, Fp fp) {

17

  if (o->result == 0 && fp)

18

    o->result = fp();

19

  return o;

20

}

21

22

unsigned int func1() { return 0; }

23

24

unsigned int func2() { return 42; }

25

26

unsigned int func3() {

27

  assert(0);

28

  return 0;

29

}

30

31

unsigned int check() {

32

  optional_t o = {and_then, 0};

33

34

  o.and_then(&o, func1)

35

    ->and_then(&o, func2)

36

    ->and_then(&o, func3);

37

38

  return o.result;

39

}

40

41

int main(void) { check(); }

Frank M. schrieb:
> unsigned int check()
> {
>   unsigned int result;
>
>   if ((result = func1()) == 0 &&
>       (result = func2()) == 0 &&
>       (result = func3()) == 0)
>   {
>     result = do_something ();
>   }
>   return result;
> }
>
> Vorteile:
> - Keine verschachtelten if-Statements
> - Die Bedingungen stehen übersichtlich untereinander
> - Die Reihenfolge der func()-Aurufe ist wie gewünscht
> - Abbruch der func()-Aufrufe, sobald ein Fehler zurückkommt
> - Keine Klammer-Orgie
> - Nur ein return

Nachteil: Es ist auf den ersten Blick schwer nachzuvollziehen was der 
Code tut. Und das macht leider alle anderen "Vorteile" zunichte.

Es gibt sicher nicht viele legitime Anwendungsfälle von GOTO, aber hier 
wäre es definitv eine Option: Es gibt nur ein return und dennoch ist 
sonnenklar was passiert.

Walter Kollascheck schrieb:
> sind Zeiger auf Funktionen
> wahrscheinlich der beste Weg einen übersichtlich Code zu bekommen!

ich melde dann schon mal wiederspruch an!
ich sehe hier keinen echten sinn/zwang/vorteil von function pointer 
verwendung.


mt

Also bei manchen Vorschlägen hier bekommt man echt Augenkrebs. Es geht 
darum möglichst wartbaren Code zu schreiben. Da bleibt man dann lieber 
gleich bei mehreren returns bevor man solche wilden Konstrukte bastelt.

Peter Petersson schrieb:
> Mehrfache Returns sind nicht per se schlecht.

das sehe ich auch so und scheue auch nicht davor zurück wenige/viele - 
wenn es sinnig erschein, einzusetzen.


mt

Apollo M. schrieb:
> ich sehe hier keinen echten sinn/zwang/vorteil von function pointer
> verwendung.

Die Frage ist im Prinzip gleich zu:
Ich habe mehrere ints a1, a2, a3,... und muss damit irgendetwas machen. 
Da sagt doch auch jeder nimm ein Array. Der einzige Unterschied ist halt 
das nicht jeder 'sattelfest' mit Funktionenpointern ist.

Apollo M. schrieb:
> ich sehe hier keinen echten sinn/zwang/vorteil von function pointer
> verwendung.

Der Vorteil von Schleifen ist, man muß sich nur einen einzigen Durchlauf 
anschauen, verstehen und testen.
Ein weiterer Vorteil ist, man kann sehr bequem Elemente hinzufügen oder 
löschen. Man muß dazu nicht mal den Code anfassen, sondern nur das 
Array.
Für das Schleifenende nehme ich gerne einen Null-Pointer als letztes 
Element. Dann kann die Funktion auch über verschiedene Arrays laufen.
Ich nehme oft schon ab 2 gleichen Aktionen eine Schleife. Damit 
vermeidet man optimal copy&paste Fehler.

mh schrieb:
> Wenn eine der Funktionen plötzlich Argumente braucht, muss man
> alles wieder ändern, oder Ausnahmen einführen.

Das sehe ich ebenfalls so.

Aber selbst wenn garantiert werden kann, dass die Funktionen auch
zukünftig immer vom selben Typ sind, gefällt mir hier die Methode ohne
Schleife besser:

1

int check1(void) {                   int check2(void) {

2

  int res;                             typedef int (*func_t)(void);

3

                                       static func_t funcs[] = {

4

  if( (res = func1()) ||                 func1, func2, func3, func4, 0

5

      (res = func2()) ||               };

6

      (res = func3()) ||               int res;

7

      (res = func4())  )

8

    return res;                        for(func_t *f = funcs; *f; f++) {