If Abfrage in C - Frage zu Verkürzung

W.S. schrieb:
> Das Problem dabei ist der völlig unmathematische Entwurf von C.
Er ist aber sehr maschinennah:

1

if ( (PINA & 0x01) != 0 ) { test1(); } // verkürzt

ich muss nicht ein Register (PINA) mit 1 ver-unden und dann hinterher 
nochmal mit 0 vergleichen. Der Schon nach der Berechnung des Ausdrucks 
PINA&1 stehen die Flags im Prozessor richtig und können ausgewertet 
werden. Ein zusätzlicher Vergleich auf "ungleich Null" ist unnötig.

W.S. schrieb:
> Die Version mit dem ? ist bloß kryptischer und unleserlicher
Verilog kann das auch. Ich hätte da den Beitrag 
Beitrag "Re: Entscheidungsoperation IF/else oder ?" mit dem Link auf den 
Fragezeichenoperator...  ;-)

Was ich hier einmal betonen möchte ist, dass in der Compiler hier in 
allen drei Fällen vermutlich den selben Code generieren würde (und 
Ausnahmen bestätigen die Regel).
Das bedeutet dass man in C den Code ruhig so schreiben kann, wie es am 
besten lesbar ist.
So würde z.B. wenn es die Architektur unterstützt z.B. ein 
Bittest-Befehl erzeugt werden (weiss nun nicht, ob ein AVR so was hat), 
wenn dieser Vorteile gegenüber einem "AND" Befehl hat.

(Randbedingungen:
1. der Optimizer muss aktiv sein (z.B. -O2)
2. Die Inhalt der Variable "i" wird später nicht für andere Dinge 
verwendet)

ZigZeg

W.S. schrieb:
> wenn das in C so vorgesehen wäre. Ist es aber nicht. Stattdessen braucht
> man ellenlange Headerdateien, um mittels Präprozessor etwas
> vergleichbares hinzukriegen. Aber Präprozessor-Akrobatik ist was anderes
> als die Syntax von C.

naja, die Header braucht es in erster Linie, damit ich statt "Bit 4" 
einen symbolischen Namen nehmen kann. Wenn ich "Bit 4" meine sage ich in 
C einfach

1

if (PORTA & (1<<4))

ZigZeg

Dieselwolf schrieb:
> Nob schrieb:
>>Irgendwo habe ich dann mal gelesen in C sei das alles viel bequemer.
>
> Du beherrscht ASM? Dann bleibe dabei -warum willst Du Dir so eine
> Gaukelsprache wie C beibringen?

Stimmt, über den Tellerrand zu schauen ist auch wirklich völliger 
Unsinn. Schuster bleib bei Deinen Leisten!

ZigZeg

Kai S. schrieb:
> Schuster bleib bei Deinen Leisten!

Deine_m_. Der Leisten.

W.S. schrieb:
> Ob auf einer konkreten Maschine das verunden einer Variablen mit einer
> Konstanten tatsächlich irgendwelche Flags setzt oder nicht, kann man
> allein im Manual zu der betreffenden Architektur nachlesen.

Kennst du eine, bei der das nicht der Fall wäre?

C ist in erster Linie so entworfen worden, dass es die Fähigkeiten
der PDP-11-CPU bestmöglich in eine Sprache abbilden konnte, die mehr
abstrahiert als Assembler, ohne dass man dabei zwangsweise die
Effektivität einbüßen muss.  Das sieht man an den Bitoperationen
hier (zum Vergleich: Pascal als Lehrsprache hat sowas nicht¹), aber
auch an Konstrukten wie *cp++.  Hätte man derartige Konstrukte nicht
irgendwie in eine höhere Programmiersprache rübergerettet, wären die
Betriebssysteme weiter aufwändig (und fehleranfällig) in Assembler
gehackt worden.

Andererseits dürfte C natürlich heutzutage den umgekehrten Effekt auf
viele CPUs haben: man entwirft sie so, dass sich C möglichst effektiv
drauf implementieren lässt.  Das ist für den AVR dokumentiert, und
die Cortexe haben ja ebenfalls als Entwurfsziel, dass man sie komplett
ohne (expliziten) Assemblercode programmieren kann.

Sich darüber zu streiten, ob das nun gut ist oder nicht, ist ziemlich
müßig.

¹) Bevor die Programmiersprachenglaubenskrieger jetzt alle auffahren:
ja, aktuelle Pascal-Dialekte haben sowas.  Das Wirthsche Pascal, etwa
zur gleichen Zeit wie C entstanden, nur mit einem völlig anderen
Fokus (Lehrsprache vs. Betriebssystemimplementierung) hatte es jedoch
nicht.

Lothar Miller schrieb:
> Schon nach der Berechnung des Ausdrucks
> PINA&1 stehen die Flags im Prozessor richtig und können ausgewertet
> werden.

Wenn es Flags gibt. Bei MIPS (wie PIC32) gibt es sie nicht...

> Ein zusätzlicher Vergleich auf "ungleich Null" ist unnötig.

...weshalb ein bedingter Sprungbefehl zwei Register vergleicht und 
abhängig davon springt.

Rufus Τ. Firefly schrieb:
> Kai S. schrieb:
>> Schuster bleib bei Deinen Leisten!
>
> Deine_m_. Der Leisten.

Natürlich "der" Leisten. Aber ein Schuster mit nur einem Leisten wird 
wohl kein erfolgreicher Schuster sein.
Als Sprichwort wird aber wohl beides verwendet - interessant!

Jörg Wunsch schrieb:
> W.S. schrieb:
>> Ob auf einer konkreten Maschine das verunden einer Variablen mit einer
>> Konstanten tatsächlich irgendwelche Flags setzt oder nicht, kann man
>> allein im Manual zu der betreffenden Architektur nachlesen.
>
> Kennst du eine, bei der das nicht der Fall wäre?

Mal abgesehen davon, dass es ziemlich schnurz ist, die eine Maschine 
genau verundet:  Ja, es gibt auch Machinen, bei der ein AND keine 
Flags setzt; etwa auf Maschinen, die (effektiv) kein PSW haben.  Ein 
Beispiel ist Infineon TriCore.

A. K. schrieb:
> ...weshalb ein bedingter Sprungbefehl zwei Register vergleicht und
> abhängig davon springt.
Das weiß der Compiler und fügt diesen Vergleich dann eigenhändig ein.

W.S. schrieb:
> Man könnte dort schreiben
> if (PortA.4) DoSomething();
Solche prozessorabängigen Erweiterungen gabs schon für den 8051. Und der 
Lohn? Bei einem Prozessor- oder nur Compilerwechsel viel Handarbeit.

> ( in Assembler
>   BTFSC PortA,4
>   CALL  DoSomeThing
> )
> wenn das in C so vorgesehen wäre. Ist es aber nicht.
Ein brauchbarer C-Compiler macht aber genau das aus dem "Maskencode".

Welche Sprache ist deiner Meinung nach geeigneter und/oder orthogonaler?

Jörg Wunsch schrieb:
> Kennst du eine, bei der das nicht der Fall wäre?

Klassische Statusregister mit Flags sind mitnichten selbstverständlich. 
Weil Flags singuläre Ressourcen sind, die im Highend-Bereich erheblichen 
Aufwand mit sich bringen.

Neben MIPS war da beispielsweise DEC Alpha eine Architektur ohne Flags. 
PowerPC wiederum hat statt dessen einen separaten Satz von 8 Registern 
für Status-Resultate, bei Intel IA64 sind es noch ein paar mehr. HPs PA 
übersprang den Folgebefehl anhängig vom Resultat eines Vergleichs.

Die x86 Implementierungen treiben grossen Aufwand, um trotz klassischem 
Statusregister nicht dauernd über die eigenen Füsse zu stolpern, dennoch 
entstehen nicht selten unerwünschte und bremsende Abhängigkeiten.

In der Anfangsphase der 8-Bit Mikroprozessoren gab es welche, die 
allenfalls ein Carry-Flag hatten, aber bei Null- oder Vorzeichentests im 
Sprung direkt den Akku überprüften (RCA 1802, NS SC/MP).

W.S. schrieb:
> Die Version mit dem
> ? ist bloß kryptischer und unleserlicher, weswegen sie bei vielen
> C-Programmierern den Vorzug hat.

Du wirst keinen Programmierer finden, der völlig auf "if" verzichtet.
Ein guter Programmierer setzt immer jeweils den Operator ein, der für 
die konkrete Aufgabe am besten ist.

Der "?" Operator liefert im Gegensatz zum "if" einen Wert zurück. Das 
kann mit "if" dann wirklich sehr umständlich und kompliziert werden und 
auch der erzeugte Code wird größer und langsamer.

Sind dagegen nur verschiedene Anweisungen auszuführen, wird man dafür 
kaum den "?" Operator benutzen.

Peter Dannegger schrieb:
>> ? ist bloß kryptischer und unleserlicher, weswegen sie bei vielen
>> C-Programmierern den Vorzug hat.
>
> Du wirst keinen Programmierer finden, der völlig auf "if" verzichtet.

Dafür sehr viele, die den ternären Operator meiden wie der Teufel das
Weihwasser und nur benutzen, wenn es gar nicht anders geht.  Aber das
passt halt nicht in W. S.' Weltbild.

W.S. schrieb:
> Die Version mit dem
> ? ist bloß kryptischer und unleserlicher, weswegen sie bei vielen
> C-Programmierern den Vorzug hat.

Im Gegenteil: Die (richtige) Anwendung des ?-Operators fördert die 
Lesbarkeit von C-Programmen. Man kann in C manches kurz und knackig 
formulieren, wofür man in anderen Sprachen eine ganze Litanei 
runtersabbeln muss.

Natürlich kann man in C sehr kryptisch programmieren. Das ist aber 
nicht unbedingt das Ziel des gemeinen C-Programmierers.

Du ratterst hier daher lediglich Vorurteile runter, die man schon in den 
70er Jahren gehört hat, als in Deutschland noch kaum jemand C überhaupt 
kannte. Wie Du am Erfolg von C erkennen kannst (immerhin werden 
mittlerweile damit ganze Betriebssysteme geschrieben), bist Du mit 
Deinen Argumenten irgendwo hinter irgendeinem Planeten auf diesem 
Sonnensystem stehengeblieben.

Was wäre denn für Dich die ideale Programmiersprache?

Hier hast Du eine klitzekleine Auswahl (Vorsicht, Humor nützlich!):

  http://web.archive.org/web/20130930062739/http://helloworldsite.he.funpic.de/hello.htm

Kai S. schrieb:
> Das bedeutet dass man in C den Code ruhig so schreiben kann, wie es am
> besten lesbar ist.

Dein Wort in Gottes Ohr. So mancher C-Programmierer ist der Meinung, er 
müsste kryptischen Scheiß zusammenschreiben, obwohl er gerade gar nicht 
am IOCCC teilnimmt.

Klammern sind für Noobs!

1

if (PINA & 0x01) test1(); // voll krass verkürzt, alter

Bzgl. des ?-Operators:
Ich schreibe (und lese) jedenfalls lieber

1

return isRunning ? GetNextValue() : sDefaultValue;

als

1

if(isRunning)

2

{

3

 return GetNextValue();

4

}

5

else

6

{

7

 return sDefaultValue;

8

}

1

PINA&0x01?a():b();

Der Rückgabetyp von a() und b() muss gleich sein

Dieselwolf schrieb:
> Boris schrieb:
>>Ich schreibe (und lese) jedenfalls lieber....
>
> Bis Du den Quelltext nach 3-4 Jahren mal wieder in die Hand bekommst

Gerade dann ist das schneller, einfacher und übersichtlicher.
Der ternäre Operator ist ein Operator wie jeder andere auch. Kein Grund 
ihn nicht einzusetzen wo er Sinn macht und einem das Leben leichter 
machen kann.

Di Pi schrieb:
> Der Rückgabetyp von a() und b() muss gleich sein

Es gelten auch da die üblichen Regeln für Operatoren.

Dieselwolf schrieb:
> Karl-Heinz behauptete:
>>Gerade dann ist das schneller, einfacher und übersichtlicher.
>
> Siehst Du: Für Dich ist die eine Variante übersichtlicher, für einen
> Anderen die Andere.

Was findest du übersichtlicher

1

  if( a ) {

2

    if( b )

3

      func( 1, 2 );

4

    else

5

      func( 1, 4 );

6

  }

7

  else {

8

    if( b )

9

      func( 3, 2 );

10

    else

11

      func( 3, 4 );

12

  }

Die Absicht ist klar:
Wenn a gegeben ist, dann soll die Funktion mit einem Wert von 1 als 
erstem Paramater aufgerufen werden, ansonsten mit einem Wert von 3
Wenn b wahr ist, dann soll die Funktion mit einem Wert von 2 als erstem 
Paramater aufgerufen werden, ansonsten mit einem Wert von 4.

Obiges lässt sich mit dem ternären Operator schreiben als

1

  func( a ? 1 : 3,

2

        b ? 2 : 4

3

       );

und drückt kurz und präzise genau das gewünschte aus. Und zwar ohne das 
man alle möglichen Fallunterscheidungen ausformulieren muss.
Nimm noch eine dritte Bedingung mit dazu und du ertrinkst in if-s und 
else.

Man kann das natürlich schreiben als

1

    if( a )

2

      arg1 = 1;

3

    else

4

      arg1 = 3;

5

6

    if( b )

7

      arg2 = 2;

8

    else

9

      arg2 = 4;

10

11

    func( arg1, arg2 );

und hat damit 2 temporäre Variablen, die eigentlich keiner braucht. An 
die Einfachheit und Übersichtlichkeit, die durch die Verwendung des 
ternären Operators entsteht, kommt aber auch diese Variante nicht ran.

Mir kommt das eher vor, wie auf gut österreichisch:
Wozu braucht man das? Das habn wir noch nie so gemacht. Da könnt ja 
jeder kommen!

Der ternäre Operator ist ein Operator wie jeder andere auch. Er hat 
seine Bedeutung. In manchen Fällen erleichtert er das Leben. In manchen 
Fällen ist er nicht angebracht. Ja, man kann sich damit auch in den Fuss 
schiessen. Aber nur weil man sich damit einen Finger abtrennen kann, ist 
eine Kreissäge noch lange kein verteufelungswürdiges Werkzeug. Auf jeden 
Fall ist allerdings ein Taschenmesser kein Ersatz dafür, nur weil es 
damit schwerer ist, sich die Hand abzutrennen.

Boris P. schrieb:
> Ich schreibe (und lese) jedenfalls lieber
> [...]
> als
>
>

1

> if(isRunning)

2

> {

3

>  return GetNextValue();

4

> }

5

> else

6

> {

7

>  return sDefaultValue;

8

> }

9

>

Das else ist überflüssig:

1

if(isRunning)

2

{

3

  return GetNextValue();

4

}

5

return sDefaultValue;

;-)

Frank M. schrieb:
> Das else ist überflüssig:

Die geschweiften Klammern nach dem if ebenfalls. ;-)

Frank M. schrieb:
> Das else ist überflüssig:

Für den Compiler ja. Für meine Argumentation nicht ;-)

Walter Tarpan schrieb:
> Frank M. schrieb:
>> Das else ist überflüssig:
>> if(isRunning)
>> {
>>   return GetNextValue();
>> }
>> return sDefaultValue;
>>
>> ;-)
>
> Ob das dann besser lesbar ist...

Finde ich schon. Am Ende einer non-Void-Funktion sollte immer ein return 
stehen. Dem wird meine Variante eher gerecht ;-)

Aber man könnte herrlich darüber streiten, ob mehrere Ausgänge innerhalb 
einer Funktion überhaupt sinnvoll sind.

> ...aber ich muß zugeben, mir ist auch gerade langweilig genug, daß ich
> darüber diskutieren würde.

Geht mir genauso ;-)

Es ist meist ein Vorteil und selten ein Nachteil, wenn man doppelt
vorkommende Code-Passagen meidet. Für lange Passagen gilt das sowieso,
oft aber auch für kurze. Mit dem ternären Operator lässt sich doppelter
Code in vielen Fällen vermeiden.

Beispiel 1 (ohne ternären Operator, nur zur Motivation):

Schlecht:

1

  array[n+i] = array[n+i] * 2;

Gut:

1

  array[n+i] *= 2;

Denn hier sieht man sofort, dass die Quelle und das Ziel dasselbe
Array-Element ist.


Beispiel 2:

Schlecht:

1

  if(bedingung)

2

  {

3

    array[n+i] = x;

4

  }

5

  else

6

  {

7

    array[n+i] = y;

8

  }

Gut:

1

  array[n+i] = bedingung ? x : y;

Denn hier sieht man sofort, dass dem Array-Element (und nur diesem) auf
jeden Fall ein Wert zugeweisen wird. Nur die Quelle ist von der
Bedingung abhängig, nicht aber das Ziel. Deswegen sollte dieses
außerhalb des bedingt ausgeführten Codes stehen.


Bspiel 3:

Schlecht:

1

  if(bedingung)

2

  {

3

    return x;

4

  }

5

  else

6

  {

7

    return y;

8

  }

Gut:

1

  return bedingung ? x : y;

Denn hier sieht man sofort, dass die Funktion an dieser Stelle endet,
ohne Wenn und Aber. Lediglich der Rückgabewert ist an eine Bedingung
geknüpft, nicht aber die Tatsache, dass die Funktion an diese Stelle zum
Aufrufer zurückkehrt. Deswegen sollte das return außerhalb des bedingt
ausgeführten Codes stehen.

Neben der Verbesserung der Lesbarkeit und des logischen Aufbaus eines
Programms gibt es aber auch Fälle, wo der ternäre Operator sogar
zwingend erforderlich ist oder nur sehr umständlich durch andere
Konstrukte ersetzbar ist. Dazu gehört bspw. die bedingte Intialisierung
von Variablen.

Weil er so nützlich ist, gibt es ihn (teilweise mit anderer Syntax) in
den meisten gängigen Programmierprachen:

  http://en.wikipedia.org/wiki/%3F:

Einfach zu sagen "Will ich nicht, brauch ich nicht, deswegen sofort in
den Müll damit" ist deswegen ein wenig zu kurz gedacht :)

Danke für die schöne Zusammenfassung :)

W.S. schrieb:
> Sowas wie 'typedef' übrigens auch - oder
> hat jemand dazu eine wirklich stichhaltige Begründung für 'typedef'?

Man merkt, daß Du mit C nicht arbeitest, sondern es aus recht 
praxisferner Sicht kritisierst. Offensichtlich hast Du noch nie etwas 
mit Funktionspointern zu tun gehabt.

Deine Definition von "lesbarkeit" weicht auch stark von meiner ab.

Den C-Stil von Karl Heinz finde ich nun auch nicht besonders schön (für 
mich gehören zusammengehörige geschweifte Klammern in die gleiche 
Spalte, und nach öffnenden und vor schließenden runden Klammern gehört 
kein Whitespace, vor öffnende dann, wenn es sich nicht um einen 
Funktionsaufruf handelt) -- aber das sind rein kosmetische Differenzen, 
die sich bei C-Anwendern mit Erfahrung individuell einspielen und 
anpassen. Was die grundliegenden Ansichten zu C betrifft, sehen wir die 
Dinge recht ähnlich.

Ich verdiene mir meinen Lebensunterhalt seit bald 25 Jahren mit C, und 
ich habe schon ziemlich viel fremden C-Code gesehen, insofern bilde ich 
mir ein, ein gewisses Gefühl für Lesbarkeit von C-Code zu haben.

Unnötige Zwischenvariablen, mehrere Anweisungen in einer Zeile etc. sind 
das genaue Gegenteil von lesbarem Code. Code, der so formatiert ist, wie 
Deiner, landet bei mir automatisch in einem "Beautifier", um eine 
lesbare und halbwegs verbreiteten Konventionen übliche Formatierung zu 
erhalten.

W.S. schrieb:

> Zu allererst fände ich es übersichtlicher, die zugrundeliegenden Blöcke
> erkennen zu können, ohne erst nach den öffnenden Klammern suchen zu
> müssen. Schreibst du etwa immer so?

Ist eine reine Konventionssache.
Wenn mein Arbeitgeber die Klammern in einer neuen Zeile will, kriegt er 
sich auch dort. Wenn ich für mich schreibe, ist das je nach Projekt 
unterschiedlich. Lange Jahre hab ich die öffnende Klammer ans Zeilenende 
geschrieben, dann wieder ein paar Jahre in eine neue Zeile. Letzten 
Endes macht es für mich wenig Unterschied. Die schliessende Klammer 
steht in der Spalte auf jeden Fall unter der 'Anweisung' in der die 
öffnende steht. Ob da jetzt die öffnende Klammer alleine steht, oder ob 
die in dieser Zeile am Zeilenende steht, ist mit persönlich mitlerweile 
egal. Ich finde in beiden Formatierungen optisch die jeweils öffnende 
Klammer recht zuverlässig - das hat sich längst automatisiert ohne dass 
ich groß darüber nachdenken muss.
Viel wichtiger ist die konsistente Einrückung.

> etwa so:
>    if (a)
>    { if (b) func(1, 2); else func(1, 4);
>    }
>    else
>    { if (b) func(3, 2); else func(3, 4);
>    }

Wer mir allerdings so etwas als 'guten Stil' unterjubeln will, den nehm 
ich nicht mehr ernst. Sorry.


Dein einziges Argument gegen den ?: Operator ist: Ein ? in einem Code 
kommt mir seltsam vor, daher verteufle ich das erst mal.

W.S. schrieb:
> und noch besser:
>
> int tmp;
> tmp = y;
> if (bedingung) tmp = y; //Kommentar, warum
> array[beliebig komplizierte Berechnung] = tmp;

Finde ich nicht. Wie man sieht schleichen sich da auch leicht Fehler 
ein. (In der dritten Zeile meintest Du vermutlich 'x' statt 'y')
Habe ich aber erst beim 2ten lesen gesehen, es ist halt unübersichtlich.

W.S. schrieb:
> Sowas wie 'typedef' übrigens auch - oder
> hat jemand dazu eine wirklich stichhaltige Begründung für 'typedef'?

Wie willst du sowas wie int16_t definieren, wenn du keine Typedefs hast? 
#define ist zwar im Prinzip möglich, aber ich stimme mit Stroustrup 
dahingehend überein, dass man den Präprozessor so sparsam wie möglich 
verwenden sollte. Dieser Mischmasch aus zwei sehr unterschiedlichen 
Sprachen (Präprozessor / C[++]) ist nicht sauber und hinsichtlich 
Namescopes grad in grossen Projekten recht problematisch.

Unglücklich bin ich über typedef nur, was die syntaktische Seite angeht. 
In die Grammatik passen sie nicht sauber hinein. Aber das wurde 
letztlich schon mit der Erfindung von C verbockt, wo typedefs erst 
nachträglich hinzugefügt wurden.

foo schrieb:
> Bei meinen Funktionen gibt es genau einen Returnpfad.

Besonders bei größeren Funktionen mit vielen Bedingungen kann das
schnell ein ausgesprochen unübersichtliches Geschachtel werden.

foo schrieb:
> Tja, jeder wie er will.
> Bei meinen Funktionen gibt es genau einen Returnpfad.
>
>

1

> uint8 foo(void)

2

> {

3

>     uint8 r;

4

> 

5

>     if(bedingung)

6

>     {

7

>         r = 1u;

8

>     }

9

>     else

10

>     {

11

>         r = 2u;

12

>     }

13

> 

14

>     return(r);

15

> }

Noch besser, weil kürzer:

1

uint8 foo(void)

2

{

3

    uint8 r = 2u;

4

5

    if(bedingung)

6

    {

7

        r = 1u;

8

    }

9

10

    return (r);

11

}

Jörg Wunsch schrieb:
> Besonders bei größeren Funktionen mit vielen Bedingungen kann das
> schnell ein ausgesprochen unübersichtliches Geschachtel werden.

Korrekt. Bei kleineren Funktionen à la get_value() kann man es aber 
schon sehr gut so machen.

Mark Brandis schrieb:
> Korrekt. Bei kleineren Funktionen à la get_value() kann man es aber
> schon sehr gut so machen.

Also genau da, wo es sich nicht lohnt. ;-)

A. K. schrieb:
> Also genau da, wo es sich nicht lohnt. ;-)

Was soll sich da nicht lohnen? Obiges Beispiel ist extrem gut lesbar. 
Und wartbar. Und der MISRA Checker freut sich. Und überhaupt. :-)

Mark Brandis schrieb:
> Noch besser, weil kürzer:
>
>
>

1

> uint8 foo(void)

2

> {

3

>     uint8 r = 2u;

4

> 

5

>     if(bedingung)

6

>     {

7

>         r = 1u;

8

>     }

9

> 

10

>     return (r);

11

> }

12

>

Suboptimal. Wenn bedingung gegeben ist, werden überflüssigerweise 2 
Zuweisungen gemacht.

(Vielleicht ist der gcc so schlau, dass er in dem obigen 
Trivial-Beispiel die 2u-Zuweisung intern in ein "else" packt. Aber davon 
würde ich nicht unbedingt ausgehen)

MISRA C 2004:

14.7 (req): A function shall have a single point of exit at the end of 
the function.

Wenn man für die Industrie nach gewissen Prozessen und zur Erreichung 
einer festgelegten SW-Qualität fertigt bleibt oft nicht viel 
'Wahlmöglichkeit' ;-)

Mark Brandis schrieb:
> Was soll sich da nicht lohnen? Obiges Beispiel ist extrem gut lesbar.
> Und wartbar. Und der MISRA Checker freut sich. Und überhaupt. :-)

Bei einer solchen Zwergfunktion wie oben ist es für Verständnis und 
Überblick ziemlich irrelevant. Das lohnt erst wirklich bei grösseren 
Funktionen, bei denen man sich sonst stunden/tagelang wundert, weshalb 
der Aufräumcode am Schluss der Funktion manchmal ignoriert wird.

Robert K. schrieb:
> MISRA C 2004:
>
> 14.7 (req): A function shall have a single point of exit at the end of
> the function.

Ich muss da Jörg schon Recht geben. Wenn man das bei größeren Funktionen 
ohne wenn und aber durchhalten will, dann muss man manchmal ziemliche 
Verrenkungen machen. Man schleppt dann den Return-Code durch alle 
möglichen Fallunterscheidungen (evtl. über mehrere Ebenen) mit.

Ein vorzeitiges bedingtes return kann da schon mal Klarheit im Code 
schaffen. Danach kanns nämlich meist unbedingt (d.h. auf höchster Ebene 
in der Funktion) weitergehen.

Frank M. schrieb:
> Robert K. schrieb:
>> MISRA C 2004:
>>
>> 14.7 (req): A function shall have a single point of exit at the end of
>> the function.
>
> Ich muss da Jörg schon Recht geben. Wenn man das bei größeren Funktionen
> ohne wenn und aber durchhalten will, dann muss man manchmal ziemliche
> Verrenkungen machen. Man schleppt dann den Return-Code durch alle
> möglichen Fallunterscheidungen (evtl. über mehrere Ebenen) mit.

Dann sind vielleicht die Funktionen auch einfach zu groß. Wer eine 
riesige Funktion hat, macht meist schon was falsch.

Frank M. schrieb:
> Ein vorzeitiges bedingtes return kann da schon mal Klarheit im Code
> schaffen. Danach kanns nämlich meist unbedingt (d.h. auf höchster Ebene
> in der Funktion) weitergehen.

Wobei man dann mit C++ besser dran ist. Weil man Aufräumcode in 
Destruktoren lokaler Daten verfrachten kann, statt sie an jenes Ende der 
Funktion zu packen, das beim vorzeitigen C-return links liegen gelassen 
wird.

Michael schrieb:
> Und der gcc ist natürlich - wie so ziemlich jeder Compiler der letzten
> zwanzig Jahre - clever genug, das zu optimieren.

Die Welt besteht nicht nur aus gcc.

Du hast leider keine Ahnung, wie (teilweise absichtlich!) dumm manche 
Compiler wirklich sind. Schau Dir den XC8 PIC-Compiler an. Der streut 
nicht nur überflüssige Befehle in den erzeugten Code, sondern übersetzt 
Divisionen und Modula-Operationen mit Zweierpotenzen nicht als Schiebe- 
bzw. Maskierungsbefehle, sondern fängt tatsächlich an, echte 
int16-Divisionen draus zu machen. Da wird man ja regelrecht gezwungen, 
dass man den Code cryptischer formuliert, damit dem Compiler auf die 
Sprünge geholfen werden kann.

(Aufgefallen bei der Portierung von IRSND (dem Pendant von IRMP) auf 
PIC XC8)

A. K. schrieb:
> Wobei man dann mit C++ besser dran ist. Weil man Aufräumcode in
> Destruktoren lokaler Daten verfrachten kann, statt sie an jenes Ende der
> Funktion zu packen, das beim vorzeitigen C-return links liegen gelassen
> wird.

Da hast Du allerdings recht. Bei einem vorzeitigen return kann man schon 
mal vergessen, irgendwas wieder wegzuräumen. Und wenn man es 
tatsächlichn machen muss, dann stehts doppelt in der Funktion. Ist 
unschön und erhöht den Pflegeaufwand, stimmt.

Ausschliesslich für kleine Mikrocontroller bestimmte Compiler sind bei 
Optimierung nicht annähernd auf dem Standard von GCC. Einerseits weil 
hinter GCC 3 Jahrzehnte Optimierung für Highend-Maschinen stecken. 
Andererseits weil zu viel unerwartete Optimierung im Kundenkreis 
unerwünscht ist.

Auch unter den Kennern der Freiheitsgrade von C sieht es beispielsweise 
nicht jeder gerne, wenn die teure Division, die er eigens vor der 
Interrupt-Sperre in den Code einstreute, vom GCC seelenruhig dorthin 
verschoben wird, wo der Quotient benötigt wird. Genau mitten in die 
gesperrte Zeit hinein.

Frank M. schrieb:
> Da hast Du allerdings recht. Bei einem vorzeitigen return kann man schon
> mal vergessen, irgendwas wieder wegzuräumen. Und wenn man es
> tatsächlichn machen muss, dann stehts doppelt in der Funktion. Ist
> unschön und erhöht den Pflegeaufwand, stimmt.

Da ich mich nicht mit MISRA rumschlagen muss bin ich in solchen Fällen 
auch so frei, ab und an mal ein goto unterzubringen. Nämlich von 
Mittendrin zum  Aufräumschwanz der Funktion. Und da dort ein Label steht 
sollte dann auch der dümmste merken, dass irgendwo ein goto sein könnte.

Michael schrieb:
> Frank M. schrieb:
>> Du hast leider keine Ahnung, wie (teilweise absichtlich!) dumm manche
>> Compiler wirklich sind.
>
> Und die eine Zuweisung bringt dich jetzt um?

Nein, das hat konkret mit der einen Zuweisung nichts zu tun. Aber mit 
der Einstellung des Programmierers zum Compiler.

Viele PC-Programme werden von Version zu Version immer langsamer. Warum? 
Weil die Programmierer immer undisziplinierter werden: "Das macht schon 
der Compiler". Oder: "Wer heute keine 4GB im PC hat, ist halt draußen!".

> Vor allem immer und überall. So daß du die Nanosekunde nicht nur an der
> einen so hochkritischen Stelle einsparen willst, sondern auch in dem
> Programmteil, der sich gerade langweilt, bis der Benutzer mal wieder was
> eingegeben hat?

Es geht nicht um eine Nanosekunde, sondern um zigtausend mal 1 
Nanosekunde.

Frank M. schrieb:
> Viele PC-Programme werden von Version zu Version immer langsamer. Warum?
> Weil die Programmierer immer undisziplinierter werden:

Nö. Nicht auf der Ebene. Nicht solcher Kleinscheiss mördert die 
Performance, sondern hinzu kommende Funktionalität, die ihren Preis hat. 
Die Performance geht dann im Vorfeld verloren, bei Leuten, die die 
Kosten nicht rechtzeitig abschätzen können.

Wenn du im Profiling den Hotspot deines Programms gefunden hast, oder 
ihn sowieso schon kennst, dann kannst du dich sehr konkret diesem 
Bisschen Code widmen. Deshalb das ganze Programm auf die Nanosekunde zu 
tunen, zu Lasten der Wartbarkeit, ist nicht ratsam.

Frank M. schrieb:
> Es geht nicht um eine Nanosekunde, sondern um zigtausend mal 1
> Nanosekunde.

Also einige zig Mikrosekunden. Grosse Sache! ;-)

A. K. schrieb:
> Frank M. schrieb:
>> Viele PC-Programme werden von Version zu Version immer langsamer. Warum?
>> Weil die Programmierer immer undisziplinierter werden:
>
> Nö. Nicht auf der Ebene. Nicht solcher Kleinscheiss mördert die
> Performance, sondern hinzu kommende Funktionalität, die ihren Preis hat.

Okay, ich will mich ja auch nicht an dem "Kleinscheiss" aufhängen. Auch 
wenn Kleinvieh u.U. auch Mist macht ;-)

> Die Performance geht dann im Vorfeld verloren, bei Leuten, die die
> Kosten nicht rechtzeitig abschätzen können.

Ja, wahrscheinlich hast Du mit dieser Einschätzung recht.

:-)

1

led_out(1 << (ledCnt = ++ledCnt<8 ? ledCnt : 0));  // feed the running light

Michael schrieb:
> Und das ändert was?

Nichts.

Warum soll ich mich mit Dir über Nanosekunden unterhalten, wenn schon 
ein NOP auf einem mit 8MHz getakteten ATMega ein Vielfaches davon 
braucht?

Daher für mich hier EOD - Höflich ausgedrückt.

Frank M. schrieb:

> Daher für mich hier EOD

"End of days" mit dem Gouvernator in der Hauptrolle? Handwerklich gut 
gemachter Actionfilm, lebt hauptsächlich vom Hauptdarsteller mit etwas 
eingestreutem Mystery. Einige Lücken in der Handlung aber das ist normal 
in dem Genre. Guter Durchschnitt.
Aber hey wir sind hier doch nicht im Cineasten Forum.

Random ... schrieb:
> :-)

1

led_out(1 << (ledCnt = ++ledCnt<8 ? ledCnt : 0));  // feed the running light

Fällt durch jedes Code Review sofort durch ;-)

Mark Brandis schrieb:
> Fällt durch jedes Code Review sofort durch ;-)

Ja, wegen der fehlenden Leerzeichen vor und nach dem "<"-Operator. :-)

http://www.osnews.com/story/19266/WTFs_m

Jörg Wunsch schrieb:
> Mark Brandis schrieb:
>> Fällt durch jedes Code Review sofort durch ;-)
>
> Ja, wegen der fehlenden Leerzeichen vor und nach dem "<"-Operator. :-)

Und vor allem, weil "running light" die völlig falsche englische
Übersetzung von "Lauflicht" (was hier wohl gemeint war) ist ;-)

**rofl**
"Light Chaser" oder "Chaser Light" ....
http://thumbs.dreamstime.com/x/illustration-einer-einfachen-gl%25C3%25BChlampe-mit-den-armen-und-den-beinen-29932172.jpg