C++ pusta obsada i przecinek operatora w #define

Question

Znalazłem to podczas czytania kodu źródłowego.

#define MACRO(x) if((void) 0, (x)); else some_func(); 

Nie rozumiem w pełni przyczyn tego przecinka operatora i pustej obsady. To prawdopodobnie ma coś wspólnego z ochroną makr. Wiem, że (void)0 jest czasami używany do ochrony kaskadowych else s w makrach, takich jak w if(...) then foo(); else (void)0.

Jakieś pomysły, dlaczego występuje przecinek operatora?

edit: Zaczynam myśleć, że to ma coś wspólnego z owl(0,0).

Answer 1

Domyślam się, że trik służy do uniemożliwienia użytkownikowi zadeklarowania zmiennych w stanie if. Jak zapewne wiecie, w C++ jest to legalne to zrobić

if (int i = some_func()) { 
    // you can use `i` here 
} 
else { 
    // and you can use `i` here 
} 

Użycie operatora przecinek w tej definicji spowoduje makro wykorzystanie jak

MACRO(int i = some_func()); 

i zmusić użytkownika do korzystania tylko wyrażeń jako argument.

Answer 2

Konwersja pustych przestrzeni ma zdecydowanie zapobiec wywołaniu przeciążenia operator ,, ponieważ nie można przeciążać za pomocą parametru void. Gwarantuje to, że (void)0, nie ma wpływu.

Dlaczego jest tam operator przecinka? Dobre pytanie. Naprawdę nie wiem.

Answer 3

Wygląda to tak, jakby ktoś mógł rozpocząć pracę z kodem, który zawierał assert, wstępnie przetworzyć go i przekształcić wynik w makro. Po zdefiniowaniu NDEBUG, assert musi zmienić się w prawie nic - ale syntaktycznie nadal musi wygenerować kod zastępczy. Na przykład, masz prawo go używać w sytuacji, takich jak:

assert(x), *x = 1; 

Podczas kompilowania to z NDEBUG zdefiniowany, to nadal musi skompilować, ale assert nie powinien nic robić. Aby wesprzeć że assert definiuje się zazwyczaj coś takiego:

#undef assert 
#ifdef NDEBUG 
#define assert(x) ((void)0) 
#else 
#define assert(x) ((!!x) || __failassert(x, __FILE__, __LINE__)) 
#endif 

Tak więc, jeśli ktoś zaczął z kodem jak wyżej, a następnie spojrzał w wersji wstępnie przetworzonej (z NDEBUG zdefiniowane), że widzą coś takiego:

... a jeśli nie rozumieli kodu bardzo dobrze, mogliby pomyśleć, że ((void)0) naprawdę znaczyło/coś osiągnęło.