Warum scheinbar bedeutungslos do-while-und if-else-Anweisungen in Makros?

Makros copy/Paste text-Stücke der pre-Prozessor setzen wird, in der echte code; das makro ist Autor hofft, dass die Ersatz Gültiger code.

Gibt es drei gute "Tipps" gelingt:

Helfen, das makro Verhalten sich wie echte-code

Normale code ist in der Regel beendet durch ein Semikolon. Sollte der Nutzer anzeigen-code nicht benötigen eine...

doSomething(1) ;
DO_SOMETHING_ELSE(2)  //<== Hey? What's this?
doSomethingElseAgain(3) ;

Dies bedeutet, dass der Benutzer erwartet, dass der compiler einen Fehler erzeugen, wenn das Semikolon fehlt.

Aber die wirkliche echte gute Grund ist, dass irgendwann, das makro ist der Autor vielleicht brauchen Sie den makro-mit echter Funktion (vielleicht inlined). So sollte das makro wirklich Verhalten sich wie einer.

Also, wir haben ein makro benötigen, semi-colon.

Ein Gültiger code

Wie gezeigt, in jfm3 Antwort, manchmal ist das makro enthält mehr als eine Anweisung. Und wenn das makro verwendet wird, innerhalb einer if-Anweisung, wird dies problematisch:

if(bIsOk)
   MY_MACRO(42) ;

Dieses makro erweitert werden könnte als:

#define MY_MACRO(x) f(x) ; g(x)

if(bIsOk)
   f(42) ; g(42) ; //was MY_MACRO(42) ;

Den g - Funktion wird ausgeführt, unabhängig vom Wert der bIsOk.

Dies bedeutet, dass wir haben müssen, um fügen Sie einen Rahmen um das makro:

#define MY_MACRO(x) { f(x) ; g(x) ; }

if(bIsOk)
   { f(42) ; g(42) ; } ; //was MY_MACRO(42) ;

Ein Gültiger code 2

Wenn das makro so etwas wie:

#define MY_MACRO(x) int i = x + 1 ; f(i) ;

Hätten wir ein weiteres problem in dem folgenden code:

void doSomething()
{
    int i = 25 ;
    MY_MACRO(32) ;
}

Da würde es erweitern, wie:

void doSomething()
{
    int i = 25 ;
    int i = 32 + 1 ; f(i) ; ; //was MY_MACRO(32) ;
}

Dieser code wird nicht kompiliert, natürlich. Also, noch einmal, die Lösung ist mit einem scope:

#define MY_MACRO(x) { int i = x + 1 ; f(i) ; }

void doSomething()
{
    int i = 25 ;
    { int i = 32 + 1 ; f(i) ; } ; //was MY_MACRO(32) ;
}

Den code verhält sich korrekt wieder.

Die Kombination von semi-colon + scope-Effekte?

Es ist eine C/C++ idiom, das führt zu diesem Effekt: Die do/while-Schleife:

do
{
    //code
}
while(false) ;

Die do/while können einen Bereich erstellen, damit die Kapselung der makro-code, und muss ein Semikolon am Ende, so die Expansion in code benötigen eine.

Den bonus?

Den C++ - compiler optimieren wird, entfernt die do/while-Schleife, als die Tatsache, dass seine post-Bedingung false ist zur Kompilierzeit bekannt ist. Dies bedeutet, dass ein makro wie:

#define MY_MACRO(x)                                  \
do                                                   \
{                                                    \
    const int i = x + 1 ;                            \
    f(i) ; g(i) ;                                    \
}                                                    \
while(false)

void doSomething(bool bIsOk)
{
   int i = 25 ;

   if(bIsOk)
      MY_MACRO(42) ;

   //Etc.
}

erweitern wird korrekt als

void doSomething(bool bIsOk)
{
   int i = 25 ;

   if(bIsOk)
      do
      {
         const int i = 42 + 1 ; //was MY_MACRO(42) ;
         f(i) ; g(i) ;
      }
      while(false) ;

   //Etc.
}

und wird dann kompiliert und optimiert Sie Weg als

void doSomething(bool bIsOk)
{
   int i = 25 ;

   if(bIsOk)
   {
      f(43) ; g(43) ;
   }

   //Etc.
}

InformationsquelleAutor paercebal

Den oben genannten Antworten, die erklären, die Bedeutung dieser Konstrukte, aber es gibt einen signifikanten Unterschied zwischen den beiden, das wurde nicht erwähnt. In der Tat, es gibt einen Grund zu bevorzugen, die do ... while zu den if ... else konstruieren.

Das problem der if ... else Konstrukt ist, dass es nicht Kraft das Semikolon. Wie in diesem code:

FOO(1)
printf("abc");

Obwohl wir ausgelassen das Semikolon (durch Fehler), wird der code zu erweitern, um

if (1) { f(X); g(X); } else
printf("abc");

und wird automatisch kompilieren (obwohl einige Compiler kann die Ausgabe einer Warnung bei unreachable code). Aber die printf - Anweisung wird nie ausgeführt werden.

do ... while Konstrukt nicht ein solches problem, da die einzige gültige token nach der while(0) ist ein Semikolon.

InformationsquelleAutor ybungalobill

Jens Gustedt ist P99 preprocessor-Bibliothek (ja, die Tatsache, dass so etwas existiert, hat mich wirklich umgehauen!) verbessert die if(1) { ... } else Konstrukt in eine kleine, aber deutliche Weise durch die Definition der folgenden:

#define P99_NOP ((void)0)
#define P99_PREFER(...) if (1) { __VA_ARGS__ } else
#define P99_BLOCK(...) P99_PREFER(__VA_ARGS__) P99_NOP

Die Gründe für dieses ist, dass, im Gegensatz zu den do { ... } while(0) Konstrukt break und continue noch die Arbeit im inneren des Blocks, aber die ((void)0) erzeugt einen syntax-Fehler, wenn das Semikolon weggelassen wird, nachdem das makro aufrufen, die ansonsten überspringen Sie den nächsten block. (Es ist nicht wirklich ein "dangling else" - problem auch hier, da die else bindet an die nächste if, das ist die, die im makro.)

Wenn Sie daran interessiert sind, die Art von Dingen, die getan werden kann, mehr oder weniger sicher mit dem C-Präprozessor, check-out, Bibliothek.

InformationsquelleAutor Isaac Schwabacher

Ich glaube nicht, dass es erwähnt wurde, so betrachten Sie dieses

while(i<100)
  FOO(i++);

übersetzt werden würde, in

while(i<100)
  do { f(i++); g(i++); } while (0)

bemerken, wie i++ ausgewertet wird zweimal durch das makro. Dies kann dazu führen, dass einige interessante Fehler.

InformationsquelleAutor John Nilsson

Ich gefunden habe, ist dieser trick sehr hilfreich ist in Situationen, in denen Sie sequenziell verarbeiten, einen bestimmten Wert. Auf jeder Ebene der Verarbeitung, wenn einige Fehler oder unwirksamen Bedingung tritt auf, können Sie vermeiden, die weitere Verarbeitung und brechen früh auf. z.B.

#define CALL_AND_RETURN(x)  if ( x() == false) break;
do {
     CALL_AND_RETURN(process_first);
     CALL_AND_RETURN(process_second);
     CALL_AND_RETURN(process_third);
     //(simply add other calls here)
} while (0);

InformationsquelleAutor pankaj