Po co używać pozornie bezsensownych instrukcji do-while i if-else w makrach?

W wielu makrach C / C ++ widzę kod makra zawinięty w coś, co wydaje się pozbawioną znaczenia do whilepętlą. Oto przykłady.

#define FOO(X) do { f(X); g(X); } while (0)
#define FOO(X) if (1) { f(X); g(X); } else

Nie widzę co do whilerobi. Dlaczego po prostu tego nie napisać?

#define FOO(X) f(X); g(X)

Są do ... whilei if ... elsesą po to, aby średnik po makrze zawsze oznaczał to samo. Powiedzmy, że masz coś jak drugie makro.

#define BAR(X) f(x); g(x)

Teraz, jeśli miałbyś użyć BAR(X);w if ... elsewyciągu, w którym ciała wyciągu if nie były zawinięte w nawiasy klamrowe, dostałbyś złą niespodziankę.

if (corge)
  BAR(corge);
else
  gralt();

Powyższy kod rozwinąłby się w

if (corge)
  f(corge); g(corge);
else
  gralt();

który jest niepoprawny pod względem składniowym, ponieważ reszta nie jest już powiązana z if. Nie pomaga zawijać makr w nawiasy klamrowe, ponieważ średnik po nawiasach jest niepoprawny pod względem składniowym.

if (corge)
  {f(corge); g(corge);};
else
  gralt();

Istnieją dwa sposoby rozwiązania problemu. Pierwszym jest użycie przecinka do sekwencjonowania instrukcji w makrze bez pozbawiania go zdolności do działania jak wyrażenie.

#define BAR(X) f(X), g(X)

Powyższa wersja paska BARrozszerza powyższy kod w następujący sposób, który jest poprawny pod względem składniowym.

if (corge)
  f(corge), g(corge);
else
  gralt();

To nie działa, jeśli zamiast tego f(X)masz bardziej skomplikowany kod, który musi przejść we własnym bloku, na przykład, aby zadeklarować zmienne lokalne. W najbardziej ogólnym przypadku rozwiązaniem jest użycie czegoś takiego, do ... whileaby makro stało się pojedynczą instrukcją, która przyjmuje średnik bez zamieszania.

#define BAR(X) do { \
  int i = f(X); \
  if (i > 4) g(i); \
} while (0)

Nie musisz go używać do ... while, możesz też coś ugotować if ... else, chociaż kiedy if ... elserozszerza się wewnątrz if ... else, prowadzi to do „ wiszącego innego ”, co może sprawić, że istniejący problem z wiszącym innym jeszcze trudniej będzie znaleźć, jak w poniższym kodzie .

if (corge)
  if (1) { f(corge); g(corge); } else;
else
  gralt();

Chodzi o to, aby użyć średnika w kontekstach, w których wiszący średnik jest błędny. Oczywiście w tym miejscu można (i prawdopodobnie należy) argumentować, że lepiej byłoby zadeklarować BARjako rzeczywistą funkcję, a nie makro.

Podsumowując, do ... whilejest tam, aby obejść niedociągnięcia preprocesora C. Kiedy te przewodniki w stylu C każą ci zrezygnować z preprocesora C, martwią się o to.

Makra to kopiowane / wklejane fragmenty tekstu, które procesor umieści w oryginalnym kodzie; autor makra ma nadzieję, że zamiana wygeneruje prawidłowy kod.

Istnieją trzy dobre „wskazówki”, aby odnieść sukces:

Pomóż makrze zachowywać się jak prawdziwy kod

Normalny kod jest zwykle zakończony średnikiem. Czy użytkownik powinien wyświetlić kod, który go nie potrzebuje ...

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

Oznacza to, że użytkownik oczekuje, że kompilator wygeneruje błąd, jeśli średnik jest nieobecny.

Ale naprawdę dobrym powodem jest to, że w pewnym momencie autor makra będzie musiał zastąpić makro prawdziwą funkcją (być może wbudowaną). Tak więc makro powinno naprawdę zachowywać się jak jedno.

Powinniśmy więc mieć makro wymagające średnika.

Utwórz poprawny kod

Jak pokazano w odpowiedzi jfm3, czasami makro zawiera więcej niż jedną instrukcję. A jeśli makro zostanie użyte w instrukcji if, będzie to problematyczne:

if(bIsOk)
   MY_MACRO(42) ;

To makro można rozwinąć jako:

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

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

gFunkcja zostanie wykonana niezależnie od wartości bIsOk.

Oznacza to, że musimy dodać zakres do makra:

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

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

Utwórz poprawny kod 2

Jeśli makro przypomina:

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

Możemy mieć inny problem w następującym kodzie:

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

Ponieważ rozwinąłby się jako:

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

Oczywiście ten kod się nie skompiluje. Zatem ponownie rozwiązanie wykorzystuje zakres:

#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) ;
}

Kod znów działa poprawnie.

Łącząc efekty średnika + zakresu?

Jest jeden idiom C / C ++, który wywołuje ten efekt: Pętla do / while:

do
{
    // code
}
while(false) ;

Do / while może utworzyć zakres, w ten sposób enkapsulując kod makra, i na końcu potrzebuje średnika, przekształcając się w kod, który go potrzebuje.

Bonus?

Kompilator C ++ zoptymalizuje pętlę do / while, ponieważ fakt, że jego stan końcowy jest fałszywy, jest znany w czasie kompilacji. Oznacza to, że makro takie jak:

#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.
}

rozwinie się poprawnie jako

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.
}

a następnie jest kompilowany i optymalizowany jako

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

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

   // Etc.
}

@ jfm3 - Masz ładną odpowiedź na pytanie. Możesz także dodać, że makro idiom zapobiega również potencjalnie bardziej niebezpiecznym (ponieważ nie ma błędu) niezamierzonemu zachowaniu za pomocą prostych instrukcji „jeśli”:

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

if (test) FOO( baz);

rozwija się do:

if (test) f(baz); g(baz);

co jest poprawne pod względem składniowym, więc nie występuje błąd kompilatora, ale ma prawdopodobnie niezamierzoną konsekwencję, że zawsze będzie wywoływana g ().

Powyższe odpowiedzi wyjaśniają znaczenie tych konstruktów, ale istnieje znacząca różnica między tymi dwoma, o których nie wspomniano. W rzeczywistości nie jest to powód do preferują do ... whiledo if ... elsekonstruktu.

Problemem if ... elsekonstrukcji jest to, że nie zmusza cię do wstawienia średnika. Jak w tym kodzie:

FOO(1)
printf("abc");

Chociaż pominęliśmy średnik (przez pomyłkę), kod zostanie rozwinięty do

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

i po cichu się skompiluje (chociaż niektóre kompilatory mogą wyświetlać ostrzeżenie o niedostępnym kodzie). Ale printfoświadczenie nigdy nie zostanie wykonane.

do ... whilekonstrukcja nie ma takiego problemu, ponieważ jedynym prawidłowym tokenem po średniku while(0)jest średnik.

Oczekuje się, że kompilatory optymalizują do { ... } while(false);pętle, ale istnieje inne rozwiązanie, które nie wymagałoby takiej konstrukcji. Rozwiązaniem jest użycie przecinka:

#define FOO(X) (f(X),g(X))

lub jeszcze bardziej egzotycznie:

#define FOO(X) g((f(X),(X)))

Chociaż będzie to działać dobrze z osobnymi instrukcjami, nie będzie działać z przypadkami, w których zmienne są konstruowane i używane jako część #define:

#define FOO(X) (int s=5,f((X)+s),g((X)+s))

W tym przypadku konieczne byłoby użycie konstrukcji do / while.

Biblioteka preprocesora Jensa Gustedta P99 (tak, fakt, że coś takiego istnieje, zaskoczyła mnie też!) Poprawia if(1) { ... } elsekonstrukcję w niewielki, ale znaczący sposób, definiując:

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

Uzasadnieniem tego jest to, że w przeciwieństwie do do { ... } while(0)konstrukcji breaki continuenadal działa wewnątrz danego bloku, ale ((void)0)tworzy błąd składniowy, jeśli średnik zostanie pominięty po wywołaniu makra, co w przeciwnym razie pominie następny blok. (W rzeczywistości nie ma tutaj problemu „wiszącego innego”, ponieważ elsewiąże się z najbliższym if, czyli tym w makrze.)

Jeśli interesują Cię rzeczy, które można wykonać mniej lub bardziej bezpiecznie za pomocą preprocesora C, sprawdź tę bibliotekę.

Z niektórych powodów nie mogę skomentować pierwszej odpowiedzi ...

Niektórzy z was pokazali makra ze zmiennymi lokalnymi, ale nikt nie wspomniał, że nie można po prostu użyć żadnej nazwy w makrze! Pewnego dnia ugryzie użytkownika! Dlaczego? Ponieważ argumenty wejściowe są podstawiane w szablonie makra. A w przykładach makr używasz prawdopodobnie najczęściej używanej zmiennej nazwy i .

Na przykład, gdy następujące makro

#define FOO(X) do { int i; for (i = 0; i < (X); ++i) do_something(i); } while (0)

jest używany w następującej funkcji

void some_func(void) {
    int i;
    for (i = 0; i < 10; ++i)
        FOO(i);
}

makro nie użyje zamierzonej zmiennej i, która jest zadeklarowana na początku some_func, ale zmienna lokalna, która jest zadeklarowana w pętli do ... while makra.

Dlatego nigdy nie używaj wspólnych nazw zmiennych w makrze!

Wyjaśnienie

do {} while (0)i if (1) {} elseupewnij się, że makro jest rozwinięte tylko do 1 instrukcji. Inaczej:

if (something)
  FOO(X); 

rozwinąłby się w:

if (something)
  f(X); g(X); 

I g(X)zostanie wykonany poza instrukcją ifsterującą. Można tego uniknąć podczas używania do {} while (0)iif (1) {} else .

Lepsza alternatywa

Dzięki wyrażeniu instrukcji GNU (nie będącym częścią standardowego C) masz lepszy sposób do {} while (0)i możesz to if (1) {} elserozwiązać, po prostu używając ({}):

#define FOO(X) ({f(X); g(X);})

Ta składnia jest zgodna z wartościami zwracanymi (zauważ, że do {} while (0)nie jest), jak w:

return FOO("X");

Nie sądzę, żeby o tym wspomniano, więc zastanów się nad tym

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

zostanie przetłumaczony na

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

zauważ, jak i++makro jest oceniane dwukrotnie. Może to prowadzić do interesujących błędów.