mikrocontroller.net

Forum: PC-Programmierung C++ 17: Eure Meinung zu 'If statement with initializer'


Autor: Kaj G. (Firma: RUB) (bloody)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Hallo Leute,

mich wuerde einfach mal eure Meinung zu diesem Feature interessieren.

C++17 If statement with initializer
https://skebanga.github.io/if-with-initializer/
if (init; condition)
Ich verstehe den Zweck dahinter (Sichtbarkeit von Variablen 
beschraenken), aber ich finde, dass es die Lesbarkeit doch sehr 
verschlechtert. Gerade bei groesseren Projekten kann ich mir vorstellen, 
dass das bei einem Codereview eher stoert, da man jetzt jedes if noch 
genauer unter die Lupe nehmen muss.

Natuerlich, man muss das Feature ja nicht benutzen, schon klar.

Wie ist eure Meinung dazu?

Gruesse

Autor: Felix U. (ubfx)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Ich finde es super. Vor Allem weil man die temporären Variablen, die man 
im init Statement erzeugt, meistens auch nur im if-context benötigt und 
sie sonst außerhalb deklarieren müsste. Insofern räumt es also sogar das 
Scope außerhalb des ifs auf, weil dort eine Variable weniger rumhängt.

Beim Code Review sollte es auch nicht weiter stören, weil die Variable 
ja dann auch nur im if-context existiert.

: Bearbeitet durch User
Autor: Dussel (Gast)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
Das ist das gleiche 'Problem', wie bei Schleifen. Immer wenn ich C 
programmieren muss, vermisse ich die Deklaration von Variablen in 
Schleifenköpfen.
Bei If bin ich es noch nicht gewohnt, deshalb vermisse ich es auch 
nicht, aber wenn es sich einmal verbreitet hat, wird das auch nicht 
anders sein, als bei Schleifen.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
7 lesenswert
nicht lesenswert
Dussel schrieb:
> Immer wenn ich C programmieren muss, vermisse ich die Deklaration von
> Variablen in Schleifenköpfen.

Dann nimm doch einen halbwegs aktuellen Compiler …

Autor: Johannes S. (jojos)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
man kann auch Variablen in einen {} Block setzen, damit hat man auch den 
Gültigkeitsbereich eingegrenzt. So mache ich das gerne, das entschärft 
etwas Kopierfehler bei denen eine Variable dann evtl. nicht mehr den 
richtigen init Wert hat wenn sie wiederverwendet wird. Und das geht noch 
mit altmodischem C++98.
void myFunc()
{
  {
    int i = 0;
  }

  {
    int i = 0;
  }
}

Autor: Cyberpunk (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Ich hätte ja lieber if-statements als Ausdruck wie z.B. bei Rust, aber 
dass neue If ist auch nicht schlecht.

Autor: Timm Reinisch (Firma: privatfrickler.de) (treinisch)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Hallo,

also ich finde die If statement with initializer Variante viel lesbarer, 
weil ja sofort und eindeutig geklärt ist, dass die Variable nur für den 
if-scope gedacht ist. Wenn ich die Variable im umgebenden scope 
definieren muss, muss der Leser ja erstmal untersuchen, ob sie noch 
irgendwo gebraucht wird.

Zusammen mit structured bindings ergibt das wirklich lokale und präzise 
Ausdrücke und er der Code wird viel aussagekräftiger.

Meine Meinung

vlg
 Timm

Autor: Scott Meyers (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Kaj G. schrieb:
> Hallo Leute,
>
> mich wuerde einfach mal eure Meinung zu diesem Feature interessieren.
>
> C++17 If statement with initializer
> https://skebanga.github.io/if-with-initializer/
> if (init; condition)
> Ich verstehe den Zweck dahinter (Sichtbarkeit von Variablen
> beschraenken), aber ich finde, dass es die Lesbarkeit doch sehr
> verschlechtert. Gerade bei groesseren Projekten kann ich mir vorstellen,
> dass das bei einem Codereview eher stoert, da man jetzt jedes if noch
> genauer unter die Lupe nehmen muss.
>
> Natuerlich, man muss das Feature ja nicht benutzen, schon klar.
>
> Wie ist eure Meinung dazu?

Du hast doch schon eigentlich einen ganz guten Post dazu zitiert. 
Überzeugt Dich das nicht?

Gerade im Zusammenhang mit den Iteratoren / Algorithmen der stdlibc++ 
ist es sehr interessant. Weil es einfach den Code kürzer macht und 
oftmals ein explicit-bool-conv-op obsolet macht.

Nur eine gelöschte Codezeile ist eine gute Codezeile.

Autor: Achim S. (achs)
Datum:

Bewertung
-6 lesenswert
nicht lesenswert
Dussel schrieb:
> Immer wenn ich C programmieren muss, vermisse
> ich die Deklaration von Variablen in Schleifenköpfen.

Dussel schrieb explizit *köpfen*:
for(int i=0; i < MAX_STUFF; i++)
{
    doStuff(i);
}
/* und hier sollte i wieder unbekannt sein!! */

Das Problem in C ist doch, dass i unten weiterlebt.

Autor: Daniel Abrecht (daniel-a)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Ich finde das Feature einfach nur unnötig. Es gibt bereits einfache 
Mittel um den Scope von Variablen zu begrenzen und es verlagert den Code 
ja nur von 2 Zeilen auf eine Zeile. Ich finde alles auf eine Zeile zu 
packen reduziert nur die Lesbarkeit.

Achim S. schrieb:
> Dussel schrieb explizit *köpfen*:
> for(int i=0; i < MAX_STUFF; i++)
> {
>     doStuff(i);
> }
> /* und hier sollte i wieder unbekannt sein!! */
>
> Das Problem in C ist doch, dass i unten weiterlebt.

Nein, das tut i nicht.

: Bearbeitet durch User
Autor: gcc (Gast)
Datum:
Angehängte Dateien:

Bewertung
4 lesenswert
nicht lesenswert
gcc 7.2

Autor: mh (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Wenn man sich die Kommentare durchliest, könnte man auf den Gedanken 
kommen, dass c++17 die Definition von Variablen in der if-condition 
einführt. Neu ist allerdings nur die explizite Trennung von init und 
condition.
if(const char* hallo = "Welt") {}
ist schon in c++98 möglich. Nur
if(const char* hallo = "Welt"; false) {}
ist neu in c++17.

Autor: Johann L. (gjlayde) Benutzerseite
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Achim S. schrieb:
>
> for(int i=0; i < MAX_STUFF; i++)
> {
>     doStuff(i);
> }
> /* und hier sollte i wieder unbekannt sein!! */
> 
>
> Das Problem in C ist doch, dass i unten weiterlebt.

s:C:JavaScript:

In JavaScript werden Deklarationen zum Anfang des Gültigkeitsbereich 
gehoistet, d.h.
function fun (MAX_STUFF)
{
  doStuff (0);
  for (var i = 0; i < MAX_STUFF; i++)
  {
      doStuff (i);
  }
}

ist gleichbedeitend mit:
function fun (MAX_STUFF)
{
  var i;
  doStuff (0);
  for (i = 0; i < MAX_STUFF; i++)
  {
      doStuff (i);
  }
}

Autor: Kaj G. (Firma: RUB) (bloody)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Achim S. schrieb:
> Das Problem in C ist doch, dass i unten weiterlebt.
Nein. Dieses Verhalten kenne ich nur von Visual Studio 2003, und da ist 
das ein bekannter Bug.

Autor: Name (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Johann L. schrieb:
> In JavaScript werden Deklarationen zum Anfang des Gültigkeitsbereich
> gehoistet, d.h.

Deswegen sollte man ES2015 und let/const statt var verwenden. ;)

Autor: Dussel (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Dussel schrieb:
>> Immer wenn ich C programmieren muss, vermisse ich die Deklaration von
>> Variablen in Schleifenköpfen.
>
> Dann nimm doch einen halbwegs aktuellen Compiler …
Ok, ich meinte was anderes. Ich vermisse es, wenn ich C auf einem System 
programmieren muss, auf dem das nicht geht.

mh schrieb:
> Wenn man sich die Kommentare durchliest, könnte man auf den Gedanken
> kommen, dass c++17 die Definition von Variablen in der if-condition
> einführt. Neu ist allerdings nur die explizite Trennung von init und
> condition.
> if(const char* hallo = "Welt") {}
> ist schon in c++98 möglich.
Das wusste ich tatsächlich nicht.

Daniel A. schrieb:
> Ich finde das Feature einfach nur unnötig. Es gibt bereits einfache
> Mittel um den Scope von Variablen zu begrenzen und es verlagert den Code
> ja nur von 2 Zeilen auf eine Zeile. Ich finde alles auf eine Zeile zu
> packen reduziert nur die Lesbarkeit.
Du definierst nie eine Variable im Schleifenkopf? Das ist mir auch noch 
nicht untergekommen.

Autor: Scott Meyers (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Das ganze ist doch eine herrliche Vereinfachung einfach deswegen, weil 
nun for/if/switch nach demselben Prinzip gebildet werden können. Und 
m.E. ist jede Art von Gleichförmigkeit gut, weil man sich weniger merken 
muss ...

Autor: Nop (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wie ist das eigentlich mit dem Stackverbrauch bei Variablen-Scoping? Ist 
natürlich implementationsabhängig, aber was ist da üblich?

1) der Compiler ist schlau genug, disjunkte Scopes zu erkennen und 
verwendet dieselben Stack-Slots wieder
2) der Compiler kriegt das nicht hin und verbraucht die Summe aller 
Variablen

Im Falle von 2 würde konsequentes Scoping dann ja zu deutlich höherem 
Stackverbrauch führen.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Der Scope einer Variablen ist doch nur der theoretisch längstmögliche
Zeitraum, in dem diese Variable „lebt“.

Alle aktuellen Compiler limitieren die tatsächliche Lebensdauer auf
das notwendige Minimum.  Es ist ja nicht nur Stack, viel knapper ist
im Allgemeinen die Ressource „Register“, sodass man diese natürlich
maximal wiederverwenden können möchte.  Sowie eine Variable nicht mehr
gebraucht wird, fliegt sie da wieder raus.  Variablen, die gar nicht
gebraucht werden, bekommen folglich dann auch nie reale Ressourcen
zugewiesen.

Das setzt natürlich eingeschaltete Optimierungen voraus.

Autor: Rolf Magnus (rmagnus)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Aber soweit ich weiß, wird die Größe des Stackframes nicht dynamisch 
während der Laufzeit einer Funktion verändert, sprich: Aller benötigter 
Stack für lokale Variablen wird zu Beginn der Funktion belegt, auch wenn 
die Variablen erst später definiert werden. Oder ist das falsch? Bei 
Registern mag das natürlich anders sein.

Jörg W. schrieb:
> Dussel schrieb:
>> Immer wenn ich C programmieren muss, vermisse ich die Deklaration von
>> Variablen in Schleifenköpfen.
>
> Dann nimm doch einen halbwegs aktuellen Compiler …

Wobei "halbwegs aktuell" bedeutet, dass er nicht mehr auf dem Stand aus 
den Neunzigern des letzten Jahrhunderts sein sollte.

Johannes S. schrieb:
> man kann auch Variablen in einen {} Block setzen, damit hat man auch den
> Gültigkeitsbereich eingegrenzt.

Das mache ich auch ganz gerne. Meist wird aber aus diesem Block später 
dann eine eigene Funktion.

Cyberpunk schrieb:
> Ich hätte ja lieber if-statements als Ausdruck wie z.B. bei Rust, aber
> dass neue If ist auch nicht schlecht.

Das gibt es doch schon mit dem ?:-Operator.

Autor: Peter II (Gast)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
Jörg W. schrieb:
> Alle aktuellen Compiler limitieren die tatsächliche Lebensdauer auf
> das notwendige Minimum.

sobald die Variablen Objekte sind, wird der Destruktor am ende vom Block 
aufgerufen, so lange existiert sie. Da kann nichts optimiert werden.

Autor: Rolf Magnus (rmagnus)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Peter II schrieb:
> Jörg W. schrieb:
>> Alle aktuellen Compiler limitieren die tatsächliche Lebensdauer auf
>> das notwendige Minimum.
>
> sobald die Variablen Objekte sind, wird der Destruktor am ende vom Block
> aufgerufen, so lange existiert sie. Da kann nichts optimiert werden.

Selbstverständlich kann da optimiert werden. Solange alle Zugriffe auf 
volatile-Variablen und alle File-I/O noch stattfinden wie im Code 
angegeben, darf der Compiler da beliebig verändern (siehe "as-if rule").
Aber es ging gar nicht darum, ob der Destruktor verfrüht aufgerufen 
wird, sondern darum, ob der Speicher länger als nötig belegt wird (also 
z.B. schon bei Beginn der Funktion, obwohl das Objekt erst weiter unten 
im Code definiert ist).

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Rolf M. schrieb:
> Aber soweit ich weiß, wird die Größe des Stackframes nicht dynamisch
> während der Laufzeit einer Funktion verändert, sprich: Aller benötigter
> Stack für lokale Variablen wird zu Beginn der Funktion belegt, auch wenn
> die Variablen erst später definiert werden.

Das dürfte bei den meisten Compilern so sein.

Allerdings kann der Compiler natürlich auch auf dem Stack Variablen
überlagern, d. h. die gleiche Stackadresse kann zu verschiedenen
Zeiten für verschiedene Variablen genutzt werden.

Autor: Michael Bertrandt (laberkopp)
Datum:

Bewertung
-6 lesenswert
nicht lesenswert
Felix U. schrieb:
> Ich finde es super. Vor Allem weil man die temporären Variablen, die man
> im init Statement erzeugt, meistens auch nur im if-context benötigt

Witzbold, man KANN sie gar nicht ausserhalb verwenden.

Die Frage ist, wie oft man Variablen braucht, die bei der Auswertung des 
IFs errechnet werden und dann nur im THEN oder ELSE Fall irgendwie 
benötigt werden.

Eher selten.

Die Frage wäre auch, was an dem 'modernen' if
if(int i;(i=anzahl())>0)
{
  cout << "Anzahl: " << i;
}
oder
if(int i=anzahl();i>0)
{
  cout << "Anzahl: " << i;
}
besser und verständlicher ist als an
{
  int i;
  if((i=anzahl())>0)
  {
    cout << "Anzahl: " << i;
  }
}
oder wie ich finde übersichtlicher
{
  int i;
  i=anzahl();
  if(i>0)
  {
    cout << "Anzahl: " << i;
  }
}

Autor: Di Pi (drpepper) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Michael B. schrieb:

>
> Die Frage wäre auch, was an dem 'modernen' if
>
> ...
> 
> besser und verständlicher ist als an
>
> ...
> 
> oder wie ich finde übersichtlicher
>
> ...
> 

Weniger Zeilen, mMn besser lesbar, kein Vertun mit Scopes, ...

Autor: Ralf G. (ralg)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Michael B. schrieb:
> Witzbold, man KANN sie gar nicht ausserhalb verwenden.

Im 'if'- context !
Dein 'i' wird auch (möglicherweise!) nur im Zusammenhang mit der 
Abfrage benötigt.

Autor: Kaj G. (Firma: RUB) (bloody)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Michael B. schrieb:
> Die Frage wäre auch, was an dem 'modernen' if besser...
Beispiel (okay, Moeglicherweise ein nicht sonderlich gutes):
#include <new>

int main()
{
    if (int *ptr = new(std::nothrow) int; ptr != nullptr) {
        *ptr = 42;
        delete ptr;
    }

    *ptr = 666;   //  fehler!

    return 0;
}
Es gibt keine Moeglichkeit 'ausversehen' ausserhalb des if auf den schon 
freigegebenen Speicher zuzugreifen (use-after-free). Also eine 
Moeglichkeit, mit wenig Aufwand und wenig nachdenken, kritische 
Sicherheitsluecken zu vermeiden. Ganz ohne das man da extra {} setzen 
muss. Natuerlich kann man innerhalb des if nach dem delete immer noch 
mist machen, aber es ist auf diesen (im idealfall sehr kleinen) Scope 
begrenzt.

Bei deiner Methode besteht diese Gefahr aber.
#include <new>

int main()
{
    int *ptr = new(std::nothrow) int;
    if (ptr != nullptr) {
        *ptr = 42;
    }

    delete ptr;
    *ptr = 666;   //  use-after-free

    return 0;
}
Und use-after-free ist ein recht haeufiger Fehler.

Und ein
#include <new>

int main()
{
    {
        int *ptr = new(std::nothrow) int;
        if (ptr != nullptr) {
            *ptr = 42;
        }

        delete ptr;
    }
    *ptr = 666;

    return 0;
}
ist auch nicht wirklich lesbarer, da es wieder eine Einrueckungstiefe 
einfuegt, die man mit diesem Feature vermeiden kann. Aber das ist wieder 
Ansichtssache.

: Bearbeitet durch User
Autor: Nop (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg W. schrieb:

> Allerdings kann der Compiler natürlich auch auf dem Stack Variablen
> überlagern, d. h. die gleiche Stackadresse kann zu verschiedenen
> Zeiten für verschiedene Variablen genutzt werden.

Genau, aber tut z.B. ARM-GCC das auch tatsächlich?

Autor: Matthias H. (hallamen)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Nop schrieb:
> Jörg W. schrieb:
>
>> Allerdings kann der Compiler natürlich auch auf dem Stack Variablen
>> überlagern, d. h. die gleiche Stackadresse kann zu verschiedenen
>> Zeiten für verschiedene Variablen genutzt werden.
>
> Genau, aber tut z.B. ARM-GCC das auch tatsächlich?

Ja.
$ arm-none-eabi-g++ -std=c++11 -fverbose-asm -Os -g0 -S code.cpp && grep "frame =" code.s
        @ args = 0, pretend = 0, frame = 8000
$ arm-none-eabi-g++ -std=c++11 -fverbose-asm -Os -g0 -S -DTWO_SCOPES code.cpp && grep "frame =" code.s
        @ args = 0, pretend = 0, frame = 4000

code.cpp:
extern int *a, *b, *c; 

constexpr int N = 1000;

void f(int x) {
#ifdef TWO_SCOPES
    {   
#endif
        int t1[N];
        for(int i=0;i<N;i++) {
            t1[i] = a[i];
        }
        for(int i=0;i<N;i++) {
            a[b[i]] = t1[i];
        }
#ifdef TWO_SCOPES
    }   
    {   
#endif
        int t2[N];
        for(int i=0;i<N;i++) {
            t2[i] = b[i];
        }
        for(int i=0;i<N;i++) {
            b[c[i]] = t2[i];
        }
#ifdef TWO_SCOPES
    }   
#endif
}


Autor: mh (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael B. schrieb:
> Die Frage ist, wie oft man Variablen braucht, die bei der Auswertung des
> IFs errechnet werden und dann nur im THEN oder ELSE Fall irgendwie
> benötigt werden.
>
> Eher selten.
Bei mir kommt es ziemlich häufig vor, dass ich Variablen nur im 
statement-true und/oder statement-false benötige. Z.B. im zusammenhang 
mit map, set und co.
void map_bsp(std::map<int,int>& m) {
  if(auto i = m.find(42); i != m.end()) {

  }
  else {

  }
}

void set_bsp(std::set<int>& s, int v) {
  if(auto [i, flag] = s.insert(v); flag) {
    std::cout << *i << std::endl;
  }
  else {

  }
}

> Die Frage wäre auch, was an dem 'modernen' ifif(int i;(i=anzahl())>0)
> {
>   cout << "Anzahl: " << i;
> }
> oderif(int i=anzahl();i>0)
> {
>   cout << "Anzahl: " << i;
> }
Warum sollte man die erste Variante benutzen?

> besser und verständlicher ist als an{
>   int i;
>   if((i=anzahl())>0)
>   {
>     cout << "Anzahl: " << i;
>   }
> }
> oder wie ich finde übersichtlicher{
>   int i;
>   i=anzahl();
>   if(i>0)
>   {
>     cout << "Anzahl: " << i;
>   }
> }
Warum sollte man die erste Variante benutzen?

Und ja, ich finde
if(int i = anzahl(); i > 0)  {}
übersichtlicher, als deine bevorzugte Varianten. Vor allem mit deinem
int i;
i = anzahl();
...
habe ich Probleme.

Autor: jz23 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
mh schrieb:
> Vor allem mit deinem
> int i;
> i = anzahl();
> ...
> habe ich Probleme.

Ja, so ein Code kann wirklich ziemlich schnell unübersichtlich werden. 
Vor allem wenn ich mehrere Variablen gleichzeitig definiere. Da kann man 
leicht mal was vergessen. Außerdem kann man auto nicht benutzen, was 
gerade bei Datentypen mit langen Namen (bzw. Templates) viel Aufwand 
spart.
int i, j, k;
i = anzahl();
j = anzahl2();
k = anzahl3();

vs.
auto i = anzahl(), j = anzahl2(), k = anzahl3();

Autor: Rolf Magnus (rmagnus)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Michael B. schrieb:
> Die Frage ist, wie oft man Variablen braucht, die bei der Auswertung des
> IFs errechnet werden und dann nur im THEN oder ELSE Fall irgendwie
> benötigt werden.
>
> Eher selten.

Ich brauche das eigentlich ständig. Ich würde vielmehr sagen, dass ich 
eher selten die Variable danach noch brauche.

jz23 schrieb:
> Ja, so ein Code kann wirklich ziemlich schnell unübersichtlich werden.
> Vor allem wenn ich mehrere Variablen gleichzeitig definiere. Da kann man
> leicht mal was vergessen. Außerdem kann man auto nicht benutzen, was
> gerade bei Datentypen mit langen Namen (bzw. Templates) viel Aufwand
> spart.

Ich bevorzuge es auch, Variablen gleich bei der Definition mit ihrem 
Wert vorzubelegen, wenn es geht. Ich finde jedenfalls ein
int i;
i = 3;
weder lesbarer, noch eleganter als ein
int i = 3;

Und bei Klassen kommt dann natürlich noch dazu, dass die Erzeugung ggf 
umständlicher ist, wenn erst der Default-Konstruktor das Objekt erzeugt 
und dann eine Zuweisung kommt, als wenn es gleich mit dem richtigen 
Konstruktor erzeugt wird.

Autor: Carl Drexler (jcw2)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Ganz nebenbei kann man mit dieser Syntax elegant ein if-Statement inkl. 
dem darin befindlichen Block atomar ausführen. Wenn im if-initializer 
ein Objekt erzeugt wird, dessen Konstruktor z.B. die Falgs sichert und 
INT's sperrt, und dessen Destruktor am Ende des "if-Blocks" die Flags 
wieder "restored". Damit ist alles inkl. der "if-Condition" selbst 
atomar (singlecore-AVR vorausgesetzt). Es reicht ein:
if( Guard guard; <Condition> ) {
    // nö INT's!
}

Das kann man natürlich auch als separaten Block um den "if-Block" 
schreiben, aber irgendwas in dieser Art mit automatischer Destruktion 
bei Scope-Ende scheint oft genug gebraucht zu werden, daß das 
ISO-Komitee dies aufnahm. Symmetrie zu "for" spricht ja aber auch nicht 
dagegen.

Automatische Destruktion von Objekten ist der Hauptpunkt, weniger die 
Bereitstellung von n Instanzen der Zähl-Variablen i innerhalb einer 
Funktion.
Obiges Guard-Objekt belegt übrigens genau ein Byte, eine Kopie des 
Flag-Registers, und landet, entsprechend kurzen "if-Block" vorausgesetzt 
einfach in einen freien CPU-Register.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.