Mengapa menggunakan pernyataan do-while dan if-else yang tampaknya tidak berarti di makro?

Dalam banyak makro C / C ++ saya melihat kode makro dibungkus dalam apa yang tampak seperti do whileloop yang tidak berarti . Berikut ini contohnya.

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

Saya tidak bisa melihat apa yang do whiledilakukannya. Mengapa tidak menulis saja tanpa itu?

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

The do ... whiledan if ... elseada untuk membuatnya sehingga titik koma setelah makro Anda selalu berarti hal yang sama. Katakanlah Anda memiliki sesuatu seperti makro kedua Anda.

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

Sekarang jika Anda menggunakannya BAR(X);dalam sebuah if ... elsepernyataan, di mana tubuh pernyataan if tidak dibungkus dengan kurung keriting, Anda akan mendapatkan kejutan buruk.

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

Kode di atas akan berkembang menjadi

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

yang secara sintaksis salah, karena yang lain tidak lagi dikaitkan dengan if. Tidak membantu untuk membungkus barang-barang dengan kurung kurawal di dalam makro, karena titik koma setelah kurung kurawal secara sintaksis salah.

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

Ada dua cara untuk memperbaiki masalah. Yang pertama adalah menggunakan koma untuk mengurutkan pernyataan dalam makro tanpa merampasnya dari kemampuannya untuk bertindak seperti ekspresi.

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

Versi bar BARdi atas memperluas kode di atas menjadi apa yang berikut, yang secara sintaksis benar.

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

Ini tidak berfungsi jika alih-alih f(X)Anda memiliki kumpulan kode yang lebih rumit yang perlu dimasukkan dalam bloknya sendiri, katakan misalnya untuk mendeklarasikan variabel lokal. Dalam kasus yang paling umum solusinya adalah menggunakan sesuatu seperti do ... whilemenyebabkan makro menjadi pernyataan tunggal yang mengambil titik koma tanpa kebingungan.

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

Anda tidak harus menggunakan do ... while, Anda bisa memasak sesuatu dengan if ... elsebaik, meskipun ketika if ... elsemengembang di dalam if ... elseitu mengarah ke " menggantung lain ", yang bisa membuat masalah menggantung lain yang ada semakin sulit ditemukan, seperti dalam kode berikut .

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

Intinya adalah untuk menggunakan titik koma dalam konteks di mana titik koma menggantung salah. Tentu saja, pada saat ini dapat (dan mungkin harus) diperdebatkan bahwa akan lebih baik untuk menyatakan BARsebagai fungsi aktual, bukan makro.

Singkatnya, do ... whileapakah ada untuk mengatasi kekurangan preprocessor C. Ketika pemandu gaya C memberitahu Anda untuk memberhentikan preprosesor C, ini adalah jenis hal yang mereka khawatirkan.

Macro adalah copy / paste teks yang akan dimasukkan oleh pre-processor ke dalam kode asli; penulis makro berharap penggantian akan menghasilkan kode yang valid.

Ada tiga "tips" yang baik untuk berhasil dalam hal itu:

Bantu makro berperilaku seperti kode asli

Kode normal biasanya diakhiri dengan titik koma. Haruskah kode tampilan pengguna tidak memerlukan satu ...

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

Ini berarti pengguna mengharapkan kompiler untuk menghasilkan kesalahan jika titik koma tidak ada.

Tetapi alasan sebenarnya yang sangat bagus adalah bahwa pada suatu saat, penulis makro mungkin perlu mengganti makro dengan fungsi asli (mungkin diuraikan). Jadi makro harus benar - benar berperilaku seperti itu.

Jadi kita harus memiliki makro yang membutuhkan semi-colon.

Menghasilkan kode yang valid

Seperti yang ditunjukkan pada jawaban jfm3, terkadang makro berisi lebih dari satu instruksi. Dan jika makro digunakan di dalam pernyataan if, ini akan bermasalah:

if(bIsOk)
   MY_MACRO(42) ;

Makro ini dapat diperluas sebagai:

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

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

The gfungsi akan dieksekusi terlepas dari nilai bIsOk.

Ini berarti bahwa kita harus menambahkan ruang lingkup ke makro:

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

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

Menghasilkan kode yang valid 2

Jika makro adalah sesuatu seperti:

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

Kami dapat memiliki masalah lain dalam kode berikut:

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

Karena itu akan berkembang sebagai:

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

Kode ini tidak akan dikompilasi, tentu saja. Jadi, sekali lagi, solusinya menggunakan cakupan:

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

Kode berperilaku dengan benar lagi.

Menggabungkan efek semi-colon + scope?

Ada satu idiom C / C ++ yang menghasilkan efek ini: Loop do / while:

do
{
    // code
}
while(false) ;

Do / while dapat membuat ruang lingkup, dengan demikian merangkum kode makro, dan membutuhkan semi-colon pada akhirnya, sehingga berkembang menjadi kode yang membutuhkannya.

Bonusnya?

Compiler C ++ akan mengoptimalkan loop do / while, karena post-conditionnya salah diketahui pada waktu kompilasi. Ini berarti makro seperti:

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

akan berkembang dengan benar sebagai

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

dan kemudian dikompilasi dan dioptimalkan sebagai

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

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

   // Etc.
}

@ jfm3 - Anda punya jawaban yang bagus untuk pertanyaan itu. Anda mungkin juga ingin menambahkan bahwa idiom makro juga mencegah perilaku yang mungkin lebih berbahaya (karena tidak ada kesalahan) dengan pernyataan 'jika' yang sederhana:

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

if (test) FOO( baz);

memperluas ke:

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

yang secara sintaksis benar sehingga tidak ada kesalahan kompiler, tetapi memiliki konsekuensi yang mungkin tidak diinginkan yaitu g () akan selalu dipanggil.

Jawaban di atas menjelaskan arti dari konstruksi ini, tetapi ada perbedaan yang signifikan antara keduanya yang tidak disebutkan. Bahkan, ada alasan untuk lebih memilih do ... whiledaripada if ... elsemembangun.

Masalah if ... elsekonstruknya adalah bahwa itu tidak memaksa Anda untuk meletakkan titik koma. Seperti dalam kode ini:

FOO(1)
printf("abc");

Meskipun kami meninggalkan titik koma (karena kesalahan), kode akan diperluas ke

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

dan akan mengkompilasi secara diam-diam (meskipun beberapa kompiler dapat mengeluarkan peringatan untuk kode yang tidak terjangkau). Namun printfpernyataan itu tidak akan pernah dieksekusi.

do ... whilekonstruk tidak memiliki masalah seperti itu, karena satu-satunya token yang valid setelah while(0)adalah titik koma.

Meskipun diharapkan kompiler mengoptimalkan do { ... } while(false);loop, ada solusi lain yang tidak memerlukan konstruksi itu. Solusinya adalah menggunakan operator koma:

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

atau bahkan lebih eksotis:

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

Meskipun ini akan bekerja dengan baik dengan instruksi terpisah, itu tidak akan bekerja dengan kasus-kasus di mana variabel dibangun dan digunakan sebagai bagian dari #define:

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

Dengan ini akan dipaksa untuk menggunakan do / while build.

P99 preprocessor library Jens Gustedt (ya, fakta bahwa hal seperti itu ada di pikiranku juga!) Meningkatkan if(1) { ... } elsekonstruk dengan cara yang kecil tapi signifikan dengan mendefinisikan yang berikut:

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

Alasan untuk ini adalah bahwa, tidak seperti do { ... } while(0)konstruk, breakdan continuemasih bekerja di dalam blok yang diberikan, tetapi ((void)0)menciptakan kesalahan sintaksis jika titik koma dihilangkan setelah panggilan makro, yang sebaliknya akan melewati blok berikutnya. (Sebenarnya tidak ada masalah "menggantung yang lain" di sini, karena elsemengikat ke yang terdekat if, yang merupakan masalah di makro.)

Jika Anda tertarik pada hal-hal yang dapat dilakukan lebih atau kurang aman dengan preproses C, periksa perpustakaan itu.

Untuk beberapa alasan saya tidak dapat mengomentari jawaban pertama ...

Beberapa dari Anda menunjukkan makro dengan variabel lokal, tetapi tidak ada yang menyebutkan bahwa Anda tidak bisa menggunakan nama apa pun di makro! Ini akan menggigit pengguna suatu hari! Mengapa? Karena argumen input diganti ke template makro Anda. Dan dalam contoh makro Anda, Anda telah menggunakan nama variabel i yang mungkin paling sering digunakan .

Misalnya saat makro berikut

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

digunakan dalam fungsi berikut

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

makro tidak akan menggunakan variabel i yang dimaksudkan, yang dideklarasikan di awal some_func, tetapi variabel lokal, yang dideklarasikan di do ... while di makro.

Jadi, jangan pernah menggunakan nama variabel umum dalam makro!

Penjelasan

do {} while (0)dan if (1) {} elsememastikan bahwa makro diperluas menjadi hanya 1 instruksi. Jika tidak:

if (something)
  FOO(X); 

akan berkembang ke:

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

Dan g(X)akan dieksekusi di luar ifpernyataan kontrol. Ini dihindari saat menggunakan do {} while (0)dan if (1) {} else.

Alternatif yang lebih baik

Dengan ekspresi pernyataan GNU (bukan bagian dari standar C), Anda memiliki cara yang lebih baik daripada do {} while (0)dan if (1) {} elseuntuk menyelesaikannya, hanya dengan menggunakan ({}):

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

Dan sintaks ini kompatibel dengan nilai pengembalian (perhatikan bahwa do {} while (0)tidak), seperti pada:

return FOO("X");

Saya tidak berpikir itu disebutkan jadi pertimbangkan ini

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

akan diterjemahkan ke dalam

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

perhatikan bagaimana i++dievaluasi dua kali oleh makro. Ini dapat menyebabkan beberapa kesalahan menarik.