switch(Funktion()) möglich?

W.A. schrieb:
> verwendeten Programmiersprache

Programmiersprache ist C.
Compiler AtmelStudio 7.

Wenn es funktioniert, wäre es besonders "unsauber" programmiert?

good coding schrieb:
> __Son´s B. schrieb:
>> Wenn es funktioniert, wäre es besonders "unsauber" programmiert?
>
> Ja, besser testbar und einfacher zu debuggen ist die Variante mit einer
> Hilfsvariablen.

Begründung?

Peter S. schrieb:
> Funktioniert prinzipiell, ist aber kein sauberer Programmier-Stil.

DANKE, für die konstruktiven Rückantworten!

Peter S. schrieb:
> Funktioniert prinzipiell, ist aber kein sauberer Programmier-Stil.

Begründung?

good coding schrieb:
> Wilhelm M. schrieb:
>> Begründung
>
> conditional breakpoint, Variable im Debugger verändern, ..., typesicher,
> ...

In diesem switch-stmt? Wozu?

Typ-sicher?

Maxx schrieb:
> Wilhelm M. schrieb:
>> Peter S. schrieb:
>>> Funktioniert prinzipiell, ist aber kein sauberer Programmier-Stil.
>>
>> Begründung?
>
> Es erschwert das Debuggen, als dass (nicht überall) ein
> Unterbrechungspunkt nicht zwischen Auswertung des Selektors und Sprung
> zur Marke gesetzt werden kann.

Das ist wohl Geschmackssache, ob ich einzelne unbedingte BPs oder einen 
bedingten BP setze.

>
> Ein ordentliches
>

1

> var_t selector = func();

2

> switch (selector)

3

> {

4

>

>
> erfüllt seinen Zweck. ist kein wesentlicher Mehraufwand.
> Erzeugt keinen
> Overhead bei Optimierung

Was für einen Overhead?

> und hat keine [versteckten] Nebeneffekte.

Wo waren die Seiteneffekte?

Programmiersprachentheaterintendant schrieb:
> Da man bei Hochsprachen sich vom Wissen was der Compiler hinter den
> Kulissen tut trennen sollte, sind mir Sprachen lieber welche sinngemäss
> auch folgendes erlauben:
>

1

> switch(egal) {

2

> 

3

> case( function( ... )):

4

> 

5

> ...

6

> 

7

> }

8

>

Nehme aber an, dass es sich um C handelt ... da gehts dann nicht.

Programmiersprachentheaterintendant schrieb:
>> Ein ordentliches
>>

1

>> var_t selector = func();

2

>> switch (selector)

3

>> {

4

>>

>
> passt so schön zu
>

1

> var_t i = heutigerAnfang(...);

2

> for ( ; i = heutigerSchritt(...) ; i != heutigesEnde(...) )

3

> {

4

>

>
> O_o

Ja ;-)

Wenn schon, dann:

1

   switch(auto x = foo()) {

2

3

    }

Maxx schrieb:
> Wilhelm M. schrieb:
>> Maxx schrieb:
>>> Wilhelm M. schrieb:
>>>> Peter S. schrieb:
>>>>> Funktioniert prinzipiell, ist aber kein sauberer Programmier-Stil.
>>>>
>>>> Begründung?
>>>
>>> Es erschwert das Debuggen, als dass (nicht überall) ein
>>> Unterbrechungspunkt nicht zwischen Auswertung des Selektors und Sprung
>>> zur Marke gesetzt werden kann.
>>
>> Das ist wohl Geschmackssache, ob ich einzelne unbedingte BPs oder einen
>> bedingten BP setze.
>
> Du kannst keinen einzelnen unbedingten oder bedingten BP setzen (es ist
> die gleiche Anweisung.

Will ich doch auch gar nicht ;-)


> func() macht etwas.
> Du hast keine direkte Einsicht in dessen Inhalt. Wird dabei ein Zusatnd
> gewechselt?

Das ist (könnte sein) auch bei der ursprünglichen Variante so.

good coding schrieb:
> Wilhelm M. schrieb:
>> Will ich doch auch gar nicht ;-)
>
> Du willst deinen Code nicht testen?
> Ok, dann mach mal weiter so. :-(((

Testen mache ich nicht mit dem Debugger, ich schreibe Test-Fälle ... 
lies Dir den Beitrag nochmal genau durch.

good coding schrieb:
> Wilhelm M. schrieb:
>> ich schreibe Test-Fälle
>
> Das wird durch eine Hilfsvariable erleichtert!

Wie schreibst Du denn Deine Testfälle?

Achim S. schrieb:
> __Son´s B. schrieb:
>> Was spricht dagegen?
>
> Da spricht nichts gegen, es ist sauber, klein, effektiv und lesbar.

Sehe ich genauso.

Falls es C++ sein sollte, kannst Du mit einem init-stmt im 
Bedingungsteil den Scope von ggf. benötigten Bezeichnern auf das 
switch-stmt einschränken. Was dann ein Vorteil wäre.

Tom schrieb:
>
> Wen die Funktion primär irgendetwas bewirkt und zusätzlich einen Status
> zurückgibt, den man auswertet, würde ich es so besser finden:
>

1

> result_t erfolg = try_get_herrschaft(&welt);

2

> switch(erfolg)

3

> {

4

>     case OK:        display("Beuget die Knie!"); break;

5

>     case FAILED:    display("Entschuldigung, war nicht so gemeint."); 

6

> break;

7

>     case NOT_FOUND: display("Wo ist die Welt hin?"); retry_herrschaft = 

8

> false; break;

9

> }

10

>

Der Nachteil an so einer Vorgehensweise ist, dass man in den umgebenden 
Block einen Bezeichner einführt, den man u.U. nur im Block des 
switch-stmt haben möchte.

In C++ kann man folgendes schreiben:

1

switch(auto result = foo()) {

2

}

oder auch

1

switch(auto [result, reason] = foo(); result) {

2

}

Stefanus F. schrieb:
> Der Haken ist: switch/case ist in C ein spezieller Ersatz für if/else
> Ketten, welcher gewährleistet, dass jeder Sprung gleich viel Zeit in
> Anspruch nimmt.

Nope, das ist nirgends so definiert und das wäre allein schon aufgrund 
der Eigenschaften der Hardware auch praktisch unmöglich zu 
gewährleisten.

Compiler kennen diverse verschiedene Methoden, switch() Statements 
umzusetzen, die sie je nach Anzahl und Verteilung der Werte auswählen. 
Keine davon produziert jedoch auf PC-Prozessoren der letzten 20 Jahre 
eine wiederholbare und vom Wert unabhängige Laufzeit.

Auch ein Table-Switch kann aufgrund des branch target predictors von 
einer Ausführung zur nächsten unterschiedlich lange dauern, und kann 
eine vom Wert oder der Folge von Werten abhängige Laufzeit haben.

Zudem kann ein einziges geändertes oder hinzugefügtes Case-Label die 
verwendete Methode völlig umkrempeln.

Nop schrieb:
> Wilhelm M. schrieb:
>
>> Der Nachteil an so einer Vorgehensweise ist, dass man in den umgebenden
>> Block einen Bezeichner einführt, den man u.U. nur im Block des
>> switch-stmt haben möchte.
>
> Kein Problem in C:
>
>

1

> {

2

>     result_t erfolg = try_get_herrschaft(&welt);

3

>     switch(erfolg)

4

>     {

5

> ...

6

>     }

7

> }

Nö, der Bezeichner erfolg ist nach wie vor außerhalb des switch-stmt 
sichtbar, etwa direkt nach der } des switch-stmt.

Nop schrieb:
> Wilhelm M. schrieb:
>
>> Nö, der Bezeichner erfolg ist nach wie vor außerhalb des switch-stmt
>> sichtbar, etwa direkt nach der } des switch-stmt.
>
> Spielt keine Rolle, weil man deswegen den Block vor der Deklaration
> einführen kann.

Das könnte man ja auch in C++, aber ich habe es aus gutem Grund nicht 
genannt, denn es löst das Problem nicht.

> Im Übrigen geht es in diesem Thread ausweislich des Postings #3 um C,
> nicht C++, und es wäre nett, wenn Du aufhören würdest, C-Threads mit C++
> zuzuspammen.

Den Ausflug in PHP hattest Du wohl übersehen?

Nicht alles, was einen Blick über den Tellerrand bietet, ist Spam.

Nop schrieb:
> Ma W. schrieb:
>
>> Man könnte auch inline-assembly nehmen.
>
> Das wäre dann aber nicht mehr portabel. Computed goto funktioniert auf
> ARM genauso wie auf x86, wenn der Compiler es unterstützt.
>
> Da man bekanntlich nicht verfrüht optimieren soll, hat man zunächst
> einmal ja ohnehin eine Codeversion, die ohne solche Scherze auskommt.
> Sofern es was bringt, kann man dann die Version mit computed goto
> hinzufügen - und die andere per ifdef drinlassen, falls man das mal mit
> einem Compiler durchziehen will, der das nicht unterstützt.

Jo, genau. Das kannst Du per ifdef doch auch protabel machen. Oh man ...

Aus dem Konstrukt switch / if das beste heraus zu holen, ist Sache des 
Compiler.

Wilhelm M. schrieb:
> Aus dem Konstrukt switch / if das beste heraus zu holen, ist Sache des
> Compiler.

Von Hand per if/else einen balancierten binary tree search zu 
implementieren ist äusserst spassbefreit, ganz besonders wenn sich 
gelegentlich was dran ändert. Und das ist jene Variante, die bei einer 
grösseren Anzahl von Werten und arg löchriger Werteverteilung oft die 
effektivste sein wird.

Da habe ich etwas los getrete, wovon ich nur wenig nachvollziehen kann.
Daher vielleicht ein konkretes Bsp das nicht korrekt (vollkommen 
unkontrolliert) läuft;

Es handelt sich um 2 Selbsthaltungen, die erst nach bestimmten 
Startbedingungen/-routinen ablaufen sollen. Daher der default-Block.

1

default:                

2

switch(Entprell_PB2())  //Selbshaltung, 1-Impuls=ON, 2-Impuls=gelöscht=OFF

3

{

4

  case 1:  PB2_high=1;  break;    // Taster/Schalter=ON

5

  case 2:  PB2_high=0;  break;    // Taster/Schalter=OFF

6

}

7

if(PB2_high)  LED_HELL_ON;

8

else    LED_ALLE_OFF;

9

10

switch(Entprell_PB1())  // Selbshaltung, 1-Impuls=ON, 2-Impuls=gelöscht=OFF

11

{

12

  case 1:  PB1_high=1;  break;    // Taster/Schalter=ON

13

  case 2:  PB1_high=0;  break;    // Taster/Schalter=OFF

14

}      

15

if(PB1_high)  LED_DUNKEL_ON;

16

else    LED_ALLE_OFF;

17

18

break;

Mir ist bewusst, dass der eine oder Andere diese switch-Schreibweise 
"unsauber" findet.
Aber wo steckt der konkrete Fehler?

__Son´s B. schrieb:
> Aber wo steckt der konkrete Fehler?

Ein konkreter Fehler ist da nicht zu sehen, nur potentielle Fehler. 
Was geschieht, wenn die Funktionen "Entprell_XX" andere Werte als 1 oder 
2 zurückliefern? Welchen Wert haben die Variablen PB1_high/PB2_high?

Warum rufst Du die Macros "LED_HELL_ON" etc. nicht direkt in Deinen 
beiden switch-Statements auf, und verwendest die zusätzlichen Variablen 
PB1_high etc.? Werden die noch irgendwo anders verwendet?

Warum die unnötige Indirektion?
Besser:

1

switch(Entprell_PB1())  // Selbshaltung, 1-Impuls=ON, 2-Impuls=gelöscht=OFF

2

{

3

  case 1:  LED_DUNKEL_ON;  break;    // Taster/Schalter=ON

4

  case 2:  LED_ALLE_OFF;   break;    // Taster/Schalter=OFF

5

  default:                 break;

6

}

Rufus Τ. F. schrieb:

> Ein konkreter Fehler ist da nicht zu sehen, nur potentielle Fehler.
> Was geschieht, wenn die Funktionen "Entprell_XX" andere Werte als 1 oder
> 2 zurückliefern? Welchen Wert haben die Variablen PB1_high/PB2_high?

Entprell_XX liefert bei Flankenanstieg einen "1"-Impuls, bei 
Flankenabfall einen "2"-Impuls. Sonst "0", hier soll der letzte Zustand 
erhalten bleiben: ON oder OFF.
Daher weise PB1_high bei Flankenanstieg "1" und bei Flankenabfall eine 
"2" zu. Dies scheint mir die einfachste und flexibelste Lösung zu 
sein...

Rufus Τ. F. schrieb:
> Warum rufst Du die Macros "LED_HELL_ON" etc. nicht direkt in Deinen
> beiden switch-Statements auf, und verwendest die zusätzlichen Variablen
> PB1_high etc.? Werden die noch irgendwo anders verwendet?

Ich wollte eine universelle Taster-Überwachung schaffen, die immer und 
überall (in späteren c-Prog) einsetzbar sind.
In deisem konkreten Prog wird die Var XXX_high nicht weiter verwendet.

Nop schrieb:
> Zu einer Fehlerfrage gehört:
> 1) Welches Verhalten wurde bei welchen Eingabedaten erwartet?
> 2) Welches Verhalten wurde stattdessen bei welchen Eingabedaten
> beobachtet?

Rufus Τ. F. schrieb:
> Ein konkreter Fehler ist da nicht zu sehen, nur potentielle Fehler.

FEHLER GEFUNDEN!
Es war ein Hardwarefehler auf der Versuchs-LP.
Daher noch einmal DANKE für eure Anmerkungen!

Achim S. schrieb:
> Mir ist (nach deinen Bezeichnern zu urteilen) nicht klar, warum LED_HELL
> nur an sein darf, wenn auch LED_DUNKEL an ist.

Beide Tasten und somit deren Ausgänge, sind vollkommen unabhängig 
voneiander.
Ich möchte einen Tastenabfrage-Block, Tasten/Schalterabfrage 1-4, die in 
ihre Var XXX_high schreiben. Im Anschluss kommt erst ein Handlungsblock 
bei dem ich die Var XXX_high auswerte.

Mein oben aufgeführter Code ist ein Versuchsblock um zu sehen, was nach 
Tastenentpr. und Selbshaltung raus kommt.

Das ist ja verrückt;
wird zuerst PB2 und danach PB1 abgefragt, funktioniert PB1/Dunkel 
einwandfrei, aber keine Reaktion wenn PB2/Hell betätigt wird.

1

default:

2

switch(Entprell_PB2())

3

{

4

  case 1:  PB2_high=1;  break;

5

  case 2:  PB2_high=0;  break;  

6

}

7

if(PB2_high)  LED_HELL_ON;

8

else    LED_ALLE_OFF;

9

10

switch(Entprell_PB1())  

11

{

12

  case 1:  PB1_high=1;  break;  

13

  case 2:  PB1_high=0;  break;  

14

}

15

if(PB1_high)  LED_DUNKEL_ON;

16

else    LED_ALLE_OFF;

17

18

break;

Werden die beiden Blöcke umgetauscht, zuerst PB1-Abfrage+Auswertung und 
danach PB2, funktionieren beide Blöcke einwandfrei!

1

default:

2

switch(Entprell_PB1())  

3

{

4

  case 1:  PB1_high=1;  break;  

5

  case 2:  PB1_high=0;  break;  

6

}

7

if(PB1_high)  LED_DUNKEL_ON;

8

else    LED_ALLE_OFF;

9

10

switch(Entprell_PB2())

11

{

12

  case 1:  PB2_high=1;  break;

13

  case 2:  PB2_high=0;  break;  

14

}

15

if(PB2_high)  LED_HELL_ON;

16

else    LED_ALLE_OFF;

17

18

break;

Wo ist denn hier die Logik?

NichtWichtig schrieb:
> Wer mal im Team an Großprojekten programmieren möchte sollte sich einen
> brauchbaren Programmierstil angewöhnen.
>
> Derartiges Zeugs (switch(fun()) ... gehört nicht dazu.

Kannst Du das auch begründen?

>
> Jeden Abend läuft Axivion über den Sourcecode und liefert Warnungen und
> Verstöße gegen die coding guide lines.

Das ist kein Grund bzw. vielmehr ein Grund ggf. das Regelwerk des Tools 
anzupassen.

Wilhelm M. schrieb:
> Kannst Du das auch begründen?

Muss man das? Man legt halt in einem Team einmal die Regeln fest. Dann 
sollte man sich daran halten - der Einheitlichkeit des Codes wegen.

> Das ist kein Grund bzw. vielmehr ein Grund ggf. das Regelwerk des Tools
> anzupassen.

Wenn es eine Mehrheitsentscheidung gibt, ja. Aber wegen des Geschmacks 
eines einzelnen: nein.

Frank M. schrieb:
> Wilhelm M. schrieb:
>> Kannst Du das auch begründen?
>
> Muss man das? Man legt halt in einem Team einmal die Regeln fest. Dann
> sollte man sich daran halten - der Einheitlichkeit des Codes wegen.

Ja, entweder gibt es objektive technische Gründe, oder es ist eben nur 
eine Teamfestlegung für den Geschmack, die hier natürlich keine Relevanz 
hat.

>> Das ist kein Grund bzw. vielmehr ein Grund ggf. das Regelwerk des Tools
>> anzupassen.
>
> Wenn es eine Mehrheitsentscheidung gibt, ja. Aber wegen des Geschmacks
> eines einzelnen: nein.

Genau! Mit scheint es eine Frage des Geschmacks zu sein. Und Geschmack 
kann man / muss man nicht begründen. Dann sollte man aber seinen eigenen 
oder den Geschmack ds Teams nicht anderen aufdrücken wollen.

NichtWichtig schrieb:
> Wartbarkeit des codes

Wo liegt bei

1

switch(foo()) {

2

...

3

}

die Nichtwartbarkeit? Was wäre denn D.E. warum besser?

> debuggen

s.o. Was wäre denn D.E. warum besser?

> Verständnis derer die den code benutzen aber nicht geschrieben haben.

s.o. Was wäre denn D.E. warum besser?

> Forderungen durch Normen

Das gilt für Euch, aber nicht allgemein.

> keep it simple!

Wie wäre es denn einfacher?

Achim S. schrieb:
>Wenn es funktioniren soll, solltest Du im else-Zweig nur die eine LED
>ausmachen. Oder am Anfang alle aus und dann nur setzen (spielt bei LEDs
> meist keine Rolle).

Tatsächlich war das der Fehler!
Trotzdem verstehe ich nicht, warum beim Reihenfolgewechsel, erst PB1 
danach PB2, die Funktion iO war? Habs mehrfach ausprobiert - Zufall?

Wilhelm M. schrieb:
> Dann sollte man aber seinen eigenen oder den Geschmack ds Teams nicht
> anderen aufdrücken wollen.

Darauf wollte ich hinaus. Unter Geschmack zähle ich übrigens nicht nur 
die Wahl des Coding-Styles, sondern auch die individuelle Wahl der 
Programmiersprache. Das sollte man durchaus auch mal respektieren und 
sich die Gebetsmühle "In C++ geht das alles viel schöner als in C" ab 
und zu verkneifen. ;-)

Wilhelm M. schrieb:
> Wo liegt bei switch(foo()) {
> ...
> }
>
> die Nichtwartbarkeit?

1. Man kann sich u.U. den Rückgabewert von foo() nicht per printf() 
testweise ausgeben lassen.

Bei

1

  int rtc = foo ();

2

  switch (rtc)

3

  ...

ist das einfach:

1

  int rtc = foo ();

2

3

#ifdef DEBUG

4

  printf ("rtc = %d\n", rtc);

5

#endif

6

7

  switch (rtc)

8

  ...

2. Wird später mal die Semantik in foo() geändert, so dass zum Beispiel 
für einen ganzen Zahlenbereich der switch() gar nicht durchgeführt 
werden soll, muss man mühsam den Funktionsaufruf und den switch() wieder 
auseinanderpopeln.

Beispiel: Es wird später eine Fehlerbehandlung in foo() eingebaut. 
Fehler sollen als negative Return-Werte zurückgegeben werden und zu 
einem Abbruch der Verarbeitung führen.

Bei

1

  int rtc = foo ();

2

  switch (rtc)

3

  ...

ist das einfach:

1

  int rtc = foo ();

2

3

  if (rtc < 0)

4

  {

5

    myerror (rtc);

6

    return (rtc);

7

  }

8

9

  switch (rtc)

10

  ...

3. Breakpoint im Debugger hinter den Aufruf von foo() setzen ist beinahe 
unmöglich.

Dein Argument, dass Du keinen Debugger nutzt, ist kein Argument. Es gibt 
durchaus Gründe, einen Debugger für bestimmte Szenarien zu nutzen statt 
ein spezielles Test-Case dafür zu verwenden.

Am wenigsten geeignet sind übrigens Test-Cases, die von demselben 
Programmierer stammen, der auch den zu testenden Code geschrieben hat. 
Solche Test-Cases berücksichtigen dann nur das, was man auch schon im 
Code verzapft hat. Daher sind sie im allgemeinen ungeeignet.

Ein Debugger jedoch kann da schon mal für den einen oder anderen 
Überraschungseffekt sorgen: "Stimmt, soooo habe ich das gar nicht 
bedacht!"

Frank M. schrieb:
> Wilhelm M. schrieb:
>> Wo liegt bei switch(foo()) {
>> ...
>> }
>>
>> die Nichtwartbarkeit?
>
> 1. Man kann sich u.U. den Rückgabewert von foo() nicht per printf()
> testweise ausgeben lassen.

Ich kann z.B. im gdb einen bedingten BP setzen im switch(): foo()==42

> 2. Wird später mal die Semantik in foo() geändert, so dass zum Beispiel
> für einen ganzen Zahlenbereich der switch() gar nicht durchgeführt
> werden soll, muss man mühsam den Funktionsaufruf und den switch() wieder
> auseinanderpopeln.
>
> Beispiel: Es wird später eine Fehlerbehandlung in foo() eingebaut.
> Fehler sollen als negative Return-Werte zurückgegeben werden und zu
> einem Abbruch der Verarbeitung führen.
>
> Bei
>

1

>   int rtc = foo ();

2

>   switch (rtc)

3

>   ...

4

>

>
> ist das einfach:
>
>

1

>   int rtc = foo ();

2

> 

3

>   if (rtc < 0)

4

>   {

5

>     myerror (rtc);

6

>     return (rtc);

7

>   }

8

> 

9

>   switch (rtc)

10

>   ...

11

>

Das kann ich doch alles im switch erledigen. Wozu das if-stmt? Das ist 
für meinen Geschmack (s.o.) nun wieder das Gegenteil von KISS und 
Lokalität.


> 3. Breakpoint im Debugger hinter den Aufruf von foo() setzen ist beinahe
> unmöglich.

In der von mir genannten Art erzwingt die Schreibweise, dass der gesamte 
Wertebereich von foo() im switch abgedeckt ist / sein sollte. Dann kann 
ich in jedes case/default ein BP setzen.

Und wie gesagt: würde man hier nur dieses eine, kleine, neue feature von 
C++ nutzen (s.u.), nämlich in if-stmts und switch-stmts auch init-stmts 
einbauen zu können, so hätte man sehr viel gewonnen: hier genau 
Einfachheit und Lokalität.

> Dein Argument, dass Du keinen Debugger nutzt, ist kein Argument.

Das wollte ich nicht damit behaupten. Allerdings ist es extrem selten 
geworden ;-) C++ und strong-types lassen grüßen.

> Es gibt
> durchaus Gründe, einen Debugger für bestimmte Szenarien zu nutzen statt
> ein spezielles Test-Case dafür zu verwenden.
>
> Am wenigsten geeignet sind übrigens Test-Cases, die von demselben
> Programmierer stammen, der auch den zu testenden Code geschrieben hat.
> Solche Test-Cases berücksichtigen dann nur das, was man auch schon im
> Code verzapft hat. Daher sind sie im allgemeinen ungeeignet.

Das brauchst Du mir nicht zu erklären. Im übrigen habe ich das auch 
nicht gesagt.

> Ein Debugger jedoch kann da schon mal für den einen oder anderen
> Überraschungseffekt sorgen: "Stimmt, soooo habe ich das gar nicht
> bedacht!"

Wie schon des öfteren gesagt: statt ein Laufzeit-Debugging 
durchzuführen, sollte man seine Energie darauf verwenden, Code so zu 
gestalten, dass er nur schwer falsch und leicht richtig benutzt werden 
kann. Und gerade in dieser Hinsicht hat C nun so seine Schwächen und C++ 
seine Stärken. Zudem sehe ich bei sehr vielen C-Problemen, die hier 
immer und immer wieder besprochen werden, dass man sie in C++ nicht 
hätte. Und dass man die meisten dieser Programme einfach als C++ Code 
übersetzen könnte und dabei schrittweise die besseren Möglichkeiten 
dieser Sprache nutzen könnte. Deswegen weise ich darauf hin.

Wilhelm M. schrieb:
> Dann sollte man aber seinen eigenen oder den Geschmack ds Teams nicht
> anderen aufdrücken wollen.

Passt nicht zur Gebetsmühle:

Wilhelm M. schrieb:
> Und gerade in dieser Hinsicht hat C nun so seine Schwächen und C++ seine
> Stärken. Zudem sehe ich bei sehr vielen C-Problemen, die hier immer und
> immer wieder besprochen werden, dass man sie in C++ nicht hätte. Und
> dass man die meisten dieser Programme einfach als C++ Code übersetzen
> könnte und dabei schrittweise die besseren Möglichkeiten dieser Sprache
> nutzen könnte. Deswegen weise ich darauf hin.

Wilhelm M. schrieb:

> Ich kann z.B. im gdb einen bedingten BP setzen im switch(): foo()==42

Im gdb mag das ja gehen. Es gibt aber durchaus noch andere Debugger, 
welche zeilenoriientiert arbeiten und es nicht hinbekommen, den 
return-Wert von foo() anzuzeigen, wenn dieses innerhalb von switch() 
steht.

> Das kann ich doch alles im switch erledigen. Wozu das if-stmt? Das ist
> für meinen Geschmack (s.o.) nun wieder das Gegenteil von KISS und
> Lokalität.

Ich kann und will das nicht im switch erledigen, denn:

foo() wird noch an 100 anderen Orten aufgerufen. Soll ich dann die 
Fehlerbehandlung an 100 Stellen machen? Wenn es 200 verschiedene 
negative Return-Werte gibt, soll ich die dann alle einzeln in genau 
diesem Switch (und an hundert anderen Orten) abfackeln? Und komm mir 
bitte nicht mit gcc-Erweiterungen, dass man hier ganze Zahlenbereiche im 
switch angeben kann. Das ist kein Standard.

Ein vorzeitiges:

1

if (rtc < 0)

2

{

3

    // evtl. myerror (rtc);

4

    return rtc;

5

}

ist genau die Lösung für das geschilderte Szenario. Gerade dann, wenn 
der 201te negative Wert später hinzukommt. Dann brauche ich nämlich an 
dieser Stelle gar nichts zu ändern!

> In der von mir genannten Art erzwingt die Schreibweise, dass der gesamte
> Wertebereich von foo() im switch abgedeckt ist / sein sollte.

Das ist nur sinnvoll, wenn Du foo() nur an dieser einen Stelle im 
Programm aufrufst, siehe oben. Das ist aber praxisfremd. Im Allgemeinen 
nutzt man Funktionen, damit man wiederkehrenden Code nur einmal 
schreiben und mehrfach von verschiedenen Stellen aus aufrufen kann.

Frank M. schrieb:
> Wilhelm M. schrieb:
>
>> Ich kann z.B. im gdb einen bedingten BP setzen im switch(): foo()==42
>
> Im gdb mag das ja gehen. Es gibt aber durchaus noch andere Debugger,
> welche zeilenoriientiert arbeiten und es nicht hinbekommen, den
> return-Wert von foo() anzuzeigen, wenn dieses innerhalb von switch()
> steht.

Ja, die gibt es leider.
Und das ist der Grund, warum auch hier eben C++ besser ist:

1

if (auto result = foo(); result < 0) {

2

    handl_error(result);

3

}

4

else {

5

    switch(result) {

6

...

7

    }

8

}

Auch wenn Du es nicht magst, werde ich mir die Freiheit nehmen, darauf 
immer wieder hinzuweisen.

>> Das kann ich doch alles im switch erledigen. Wozu das if-stmt? Das ist
>> für meinen Geschmack (s.o.) nun wieder das Gegenteil von KISS und
>> Lokalität.
>
> Ich kann und will das nicht im switch erledigen:

die bessere Lösung steht oben

> foo() wird noch an 100 anderen Orten aufgerufen. Soll ich dann die
> Fehlerbehandlung an 100 Stellen machen?

Genau das wirst Du wohl machen müssen: die Fehlerbehandlung s.o.

> Wenn es 200 verschiedene
> negative Return-Werte gibt, soll ich die dann alle einzeln in genau
> diesem Switch (und an hundert anderen Orten) abfackeln?

Dazu hast Du hoffentlich eine eigene Funktion oder generischen 
Mechanismus, um Replication zu vermeiden ... alles andere wäre auch 
praxisfern.

> Und komm mir
> bitte nicht mit gcc-Erweiterungen, dass man hier ganze Zahlenbereiche im
> switch angeben kann. Das ist kein Standard.

Schon mal was von falltrough gehört? Naja, ist auch mal wider 
Standard-C++, sorry.

> Ein vorzeitiges:
>

1

> if (rtc < 0)

2

> {

3

>     // evtl. myerror (rtc);

4

>     return rtc;

5

> }

6

>

>
> ist genau die Lösung für das geschilderte Szenario. Gerade dann, wenn
> der 201te negative Wert später hinzukommt. Dann brauche ich nämlich an
> dieser Stelle gar nichts zu ändern!

Wenn Du es richtig machst, brauchst Du im switch auch nichts zu ändern. 
Und Du weißt sicher, dass man das so in C++ auch nicht machen müsste / 
würde (und die Lösung heisst jetzt nicht exception).

Frank M. schrieb:

> Bei
>

1

>   int rtc = foo ();

2

>   switch (rtc)

3

>   ...

4

>

>
> ist das einfach:
>
>

1

>   int rtc = foo ();

2

> 

3

> #ifdef DEBUG

4

>   printf ("rtc = %d\n", rtc);

5

> #endif

6

> 

7

>   switch (rtc)

8

>   ...

9

>

Und Du empfiehlst wahrscheinlich auch

1

bool rtc = is_even(x);

2

if (rtc) {

3

...

4

}

zu schreiben statt

1

if (is_even(x)) {

2

...

3

}

nehme nun ich an.

Nop schrieb:
> Wilhelm M. schrieb:
>
>> Und das ist der Grund, warum auch hier eben C++ besser ist:
>
> Irrelevant.

Der nächste C-Standard soll C2x (etwa 2022) sein. Und ich denke, dass 
viel von den "kleinen C++-Features" (s.o.) bis C++20 auch dort 
einfließen wird. Das ist natürlich noch lange hin und schade für die, 
die nicht willens sind, über den Tellerrand hinaus zu blicken.

Wilhelm M. schrieb:
> Nop schrieb:
>> Wilhelm M. schrieb:
>>
>>> Und das ist der Grund, warum auch hier eben C++ besser ist:
>>
>> Irrelevant.
>
> Der nächste C-Standard soll C2x (etwa 2022) sein. Und ich denke, dass
> viel von den "kleinen C++-Features" (s.o.) bis C++20 auch dort
> einfließen wird. Das ist natürlich noch lange hin und schade für die,
> die nicht willens sind, über den Tellerrand hinaus zu blicken.

Verschwende einfach nicht deine Zeit mit denen im Suppenteller.
Es gibt eine Vielzahl von Nicks, bei denen man einfach sein 
Antwortbedürfnis unterdrücken muß.
Aber immer klappt das nicht, wie ich selber zugeben muß ;-)

Carl D. schrieb:

>
> Verschwende einfach nicht deine Zeit mit denen im Suppenteller.
> Es gibt eine Vielzahl von Nicks, bei denen man einfach sein
> Antwortbedürfnis unterdrücken muß.

Ja, das ist wohl einerseits richtig. Andererseits gibt ja auch hier noch 
den TO und auch weitere stille Mitleser, die einfach auch mal etwas 
Neues erfahren wollen, statt ständig nur zu hören: das geht nur so, 
basta!

Wilhelm M. schrieb:
> Carl D. schrieb:
>
>>
>> Verschwende einfach nicht deine Zeit mit denen im Suppenteller.
>> Es gibt eine Vielzahl von Nicks, bei denen man einfach sein
>> Antwortbedürfnis unterdrücken muß.
>
> Ja, das ist wohl einerseits richtig. Andererseits gibt ja auch hier noch
> den TO und auch weitere stille Mitleser, die einfach auch mal etwas
> Neues erfahren wollen, statt ständig nur zu hören: das geht nur so,
> basta!

Deshalb:
>> Aber immer klappt das nicht, wie ich selber zugeben muß ;-)

Achim S. schrieb:
> Arduino F. schrieb:
>> Viele Werkzeuge sind nutzlos, in den Händen von Leuten, die damit nicht
>> umgehen können oder wollen.
>
> Das stimmt. Und ich freue mich ja auch über jedes Beispiel, wo irgendwas
> eleganter wird. Aber wieso wird hier wieder C++ als ultimativ
> hingestellt, ohne einen nachvollziehbaren Mehrwert zu zeigen.

Wie Du unten selbst zitierst, habe ich geschrieben, dass es besser geht, 
aber nicht als die nicht mehr zu verbessernde Lösung.

> Was an
>
> Wilhelm M. schrieb:
>> Ja, die gibt es leider.
>> Und das ist der Grund, warum auch hier eben C++ besser ist:
>> if (auto result = foo(); result < 0) {
>>     handl_error(result);
>> }
>
> soviel besser sein soll als
>

1

> int result;

2

> 

3

>    if(result =foo(), result < 0){

4

>        handle_error(result);

5

>    }

6

>

Der entscheidende, wenn auch bei diesem kleinen Beispiel eben zunächst 
klein ausfallende Unterschied ist die effektive Begrenzung des 
Gültigkeitsbereichs auf den Scope des if-stmts. Und das ist schon mal 
ein großer Vorteil, verhindert es doch effektiv das so oft vorkommende 
Recycling von Variablen aus Faulheit. Debuggen kann man es dann auch 
(s.o.), falls man einen schwachen Debugger hat.

> Auch in C kann ich if-Klammern überfrachten. Ist es "auto"?

Das "auto" kommt natürlich erst in generischem Code zum Tragen.

> Ist es der
> Scope von result? Die Deklarationszeile?

s.o.

Achim S. schrieb:
> Arduino F. schrieb:
>> Viele Werkzeuge sind nutzlos, in den Händen von Leuten, die damit nicht
>> umgehen können oder wollen.
>
> Das stimmt. Und ich freue mich ja auch über jedes Beispiel, wo irgendwas
> eleganter wird. Aber wieso wird hier wieder C++ als ultimativ
> hingestellt, ohne einen nachvollziehbaren Mehrwert zu zeigen. Was an
>
> Wilhelm M. schrieb:
>> Ja, die gibt es leider.
>> Und das ist der Grund, warum auch hier eben C++ besser ist:
>> if (auto result = foo(); result < 0) {
>>     handl_error(result);
>> }
>
> soviel besser sein soll als
>

1

> int result;

2

> 

3

>    if(result =foo(), result < 0){

4

>        handle_error(result);

5

>    }

6

>

.
> Auch in C kann ich if-Klammern überfrachten. Ist es "auto"? Ist es der
> Scope von result? Die Deklarationszeile? Ja, C++ wird schneller
> verändert, hat mehr Freiheiten, erlaubt filigranere Verbiegungen, ...
> aber das hier tangiert die Eigenschaften der Unterschiede nicht
> wirklich.

Wenn result kein int ist, sondern etwas, das man wieder abräumen muß, 
dann lernt man "scope" schätzen. Und natürlich das bisschen mehr 
gegenüber C, weil der Compiler aufräumt.
auto übernimmt den Typ vom Ergebnis von foo(). Wenn man z.B. 
Raketen-Flugbahnen mal in INT und mal in double berechnet. Da kann auto 
die Lebensdauer des Fluggeräts deutlich erhöhen.
Man braucht das natürlich nicht, so wie man keinen Akkuschrauber braucht 
und keine CNC-Bearbeitungsstation. Letzteres ist auch nicht so einfach 
zu bedienen, wie eine Feile und viel teuerer, wird aber trotzdem 
gekauft.

Nop schrieb:
>> Man könnte auch inline-assembly nehmen.
>
> Das wäre dann aber nicht mehr portabel. Computed goto funktioniert auf
> ARM genauso wie auf x86, wenn der Compiler es unterstützt.

Ich weise mal leise darauf hin, dass computed goto auf AVR nicht 
unterstützt wird.

S. R. schrieb:
> Nop schrieb:
>>> Man könnte auch inline-assembly nehmen.
>>
>> Das wäre dann aber nicht mehr portabel. Computed goto funktioniert auf
>> ARM genauso wie auf x86, wenn der Compiler es unterstützt.
>
> Ich weise mal leise darauf hin, dass computed goto auf AVR nicht
> unterstützt wird.

Komisch, benutze ich bei einer C++ Protothreads Implementierung mit g++ 
auf AVR.
Vielleicht weil ich mir den Compiler immer aus aktuellen Sourcen selbst 
baue und nicht einen WinAvr2010 benutze?

Edit: gerade gelesen: AVR-GCC kann keine Offsets zweier Labeladressn 
berechnen. Brauchte ich aber nicht.

Carl D. schrieb:
> S. R. schrieb:
>> Nop schrieb:
>>>> Man könnte auch inline-assembly nehmen.
>>>
>>> Das wäre dann aber nicht mehr portabel. Computed goto funktioniert auf
>>> ARM genauso wie auf x86, wenn der Compiler es unterstützt.
>>
>> Ich weise mal leise darauf hin, dass computed goto auf AVR nicht
>> unterstützt wird.
>
> Komisch, benutze ich bei einer C++ Protothreads Implementierung mit g++
> auf AVR.
> Vielleicht weil ich mir den Compiler immer aus aktuellen Sourcen selbst
> baue und nicht einen WinAvr2010 benutze?

Nein, denke genaues Lesen ist angesagt:

https://gcc.gnu.org/onlinedocs/gcc/Labels-as-Values.html

Wilhelm M. schrieb:
> Nein, denke genaues Lesen ist angesagt:
>
> https://gcc.gnu.org/onlinedocs/gcc/Labels-as-Values.html

Differenzen zwischen Label-Adressen gehen nicht, aber die braucht man 
weder für Protithreads, nicht für "Label-Arrays".
Auf alle Fälle ist "geht nicht" eine starke Verbiegung der Wahrheit.

Achim S. schrieb:
>> Gültigkeitsbereichs auf den Scope des if-stmts. Und das ist schon mal
>> ein großer Vorteil, verhindert es doch effektiv das so oft vorkommende
>> Recycling von Variablen aus Faulheit. Debuggen kann man es dann auch
>> (s.o.), falls man einen schwachen Debugger hat.
>
> Carl D. schrieb:
>> Wenn result kein int ist
>
> Das meine ich. Ich brauche unbedingt C++ (mit seinem ungleich größeren
> Sprachumfang), um für ein mögliches Debug-Szenario mit einem
> beschränkten Debugger den Scope einer general-Purpose int-Variable zu
> begrenzen. Das ist absurd!

Genau! Ich brauche C++, weil es C nicht kann! Das C das nicht kann ist 
absurd.

Was ist eine general-purpose int-Variable? Eine, die Du immer wieder 
recyclest?

> Ja, in anderen Beispielen ist der Scope interessant und Destruktoren
> oder auto. Aber nicht hier! Es geht um switch, und da ist int immer
> richtig und gut!

Ja, die alte Strategie: alles ist ein int oder ein C-String ... back to 
the 70s

> Egal was foo() zurückliefert.

Du willst also echt jeden Typ, den foo() liefert, auf ein int implizit 
wandeln. Oh, das nenne ich mal krass!

Carl D. schrieb:
> Wilhelm M. schrieb:
>> Nein, denke genaues Lesen ist angesagt:
>>
>> https://gcc.gnu.org/onlinedocs/gcc/Labels-as-Values.html
>
> Differenzen zwischen Label-Adressen gehen nicht, aber die braucht man
> weder für Protithreads, nicht für "Label-Arrays".
> Auf alle Fälle ist "geht nicht" eine starke Verbiegung der Wahrheit.

Was ich damit sagen wollte: da hat wohl einer eben nicht so richtig 
gelesen ...

Achim S. schrieb:
> Wilhelm M. schrieb:
>> Du willst also echt jeden Typ, den foo() liefert, auf ein int implizit
>> wandeln. Oh, das nenne ich mal krass!
>
> Ich vermute, Du hast Dich ein bisschen verrannt oder meinen Beitrag nur
> überflogen. Ich möchte gar nichts, switch macht.

Ich habe schon genau genau gelesen: Du möchtest gerne

1

double foo();

2

3

void test() {

4

   switch(foo()) {

5

   ...

6

   }

7

}

was aber selbst in C nicht geht.

Nop schrieb:
> Carl D. schrieb:
>> Wenn man z.B.
>> Raketen-Flugbahnen mal in INT und mal in double berechnet.
>

> Richtig macht man das so, daß man in einem einzigen Datenformat und
> einer einzigen Einheit rechnet, und zwar konsistent und überall.

Und wie stellst Du das sicher, wenn alles ein double ist?

Richtig ist, sich ein Typ-System zu schaffen, bei dem richtig gerechnet 
wird, also etwa:

1

auto distance = 13_km;

2

auto time = 1_sec;

3

4

auto speed = distance / time;

"Unsinnige" Operationen werden nicht realisiert. Dann kann fast nichts 
mehr schief gehen.