Зачем использовать в макросах явно бессмысленные операторы do-while и if-else?

Для примера с else я бы добавил выражение типа void в конце ... например, ((недействительно) 0).

Напоминаем, что конструкция do while несовместима с операторами return, поэтому конструкция if (1) { ... } else ((void)0) имеет более совместимые применения в стандарте C. А в GNU C вы предпочтете конструкцию, описанную в моем ответе.

В моем собственном ответе пропущена «проблема else, если фигурные скобки и точка с запятой», но вы забыли проблему области видимости, а также оптимизацию компилятора do / while (false) ... :-p ...

Но почему бы просто не #define FOO (X) {f (X); г (Х); }?

@korona: if (выражение) FOO (X); else ... такой код будет недопустимым, потому что у вас есть 2 оператора в предложении if.

Разве это не веский аргумент в пользу того, чтобы всегда использовать фигурные скобки в операторах if, while и for? Если вы всегда делаете это (как это требуется, например, для MISRA-C), описанная выше проблема исчезнет.

Пример запятой должен быть #define BAR(X) (f(X), g(X)), иначе приоритет оператора может испортить семантику.

Разве вы не можете избежать проблемы с болтающимся остальным, используя #define FOO(x) if (1) { ... } else (void)0?

Как сказал @SteveMelnikoff, каждая упомянутая проблема должна быть решена очень простым исправлением - добавлением скобок в каждую ветвь операторов if / while / for, даже если они содержат только один оператор. Я в основном программист PHP, но всегда везде использую фигурные скобки, даже у меня таких проблем нет :) Использовать скобки везде должно быть проще, чем использовать такие конструкции do/while(0), или я ошибаюсь?

@DawidFerenczy: хотя и ты, и я - четыре с половиной года назад - хорошо замечаем, мы должны жить в реальном мире. Если мы не можем гарантировать, что все операторы if и т. д. В нашем коде используют фигурные скобки, то упаковка макросов, подобная этой, - простой способ избежать проблем.

А что насчет этой простой конструкции: ({})? Смотрите мой ответ.

Примечание: форма if (1) {...} else void(0) более безопасна, чем do {...} while(0) для макросов, параметры которых представляют собой код, включенный в раскрытие макроса, поскольку она не изменяет поведение ключевых слов break или continue. Например: for (int i = 0; i < max; ++i) { MYMACRO( SomeFunc(i)==true, {break;} ) } вызывает неожиданное поведение, когда MYMACRO определен как #define MYMACRO(X, CODE) do { if (X) { cout << #X << endl; {CODE}; } } while (0), потому что разрыв влияет на цикл while макроса, а не на цикл for в месте вызова макроса.

@ChrisKline void(0) недопустимый код C. Кроме того, он по-прежнему не решает проблему зависания else.

@ace void(0) был опечаткой, я имел в виду (void)0. И я считаю, что этот делает решает проблему "висячего другого": обратите внимание, что после (void)0 нет точки с запятой. В этом случае свисание else (например, if (cond) if (1) foo() else (void)0 else { /* dangling else body */ }) вызывает ошибку компиляции. Вот живой пример, демонстрирующий это

Проблема не в том, что вы не можете ставить точку с запятой после блока, а в том, что эта точка с запятой является отдельным оператором, поэтому else все еще синтаксически неверен.

@ChrisKline MYMACRO( SomeFunc(i)==true, {break;} ) - плохой код. Попытка решить все возможные проблемы с помощью макросов делает макросы слишком сложными без реальных преимуществ.

"вероятно, непреднамеренно"? Я бы сказал «конечно непреднамеренно», иначе программиста нужно вытащить и расстрелять (а не жестко наказать кнутом).

Или они могут получить повышение, если они работают в трехбуквенном агентстве и тайком вставляют этот код в широко используемую программу с открытым исходным кодом ... :-)

И этот комментарий просто напоминает мне строку goto fail в недавней ошибке проверки сертификата SSL, обнаруженной в ОС Apple.

Обратите внимание, что изменение макроса на встроенную функцию изменяет некоторые стандартные предопределенные макросы, например следующий код показывает изменение в НАЗНАЧЕНИЕ и ЛИНИЯ: #include <stdio.h> #define Fmacro () printf ("% s% d \ n", НАЗНАЧЕНИЕ, ЛИНИЯ) inline void Finline () {printf ("% s% d \ n ", НАЗНАЧЕНИЕ, ЛИНИЯ); } int main () {Fmacro (); Finline (); возврат 0; } (жирные термины должны быть заключены в двойные подчеркивания - плохое форматирование!)

Есть ряд мелких, но не совсем несущественных проблем с этим ответом. Например: void doSomething() { int i = 25 ; { int i = x + 1 ; f(i) ; } ; // was MY_MACRO(32) ; } - неправильное расширение; x в расширении должно быть 32. Более сложный вопрос - что такое расширение MY_MACRO(i+7). И еще одно расширение MY_MACRO(0x07 << 6). Есть много хорошего, но есть некоторые незакрещенные и незакрашенные «i».

@Gnubie: я на случай, если вы все еще здесь, и вы еще не поняли этого: вы можете убрать звездочки и подчеркивания в комментариях с помощью обратной косой черты, поэтому, если вы наберете \_\_LINE\_\_, он отобразится как __LINE__. ИМХО, лучше просто использовать форматирование кода для кода; например, __LINE__ (не требует особого обращения). P.S. Не знаю, было ли это правдой в 2012 году; С тех пор они внесли в двигатель немало улучшений.

Признавая, что мой комментарий опоздал на шесть лет, но большинство компиляторов C на самом деле не встраивают функции inline (как разрешено стандартом)

Это не имеет ничего общего с конструкцией do ... while (0).

Правда. Но имеет отношение к теме макросов и функций, а также к тому, как написать макрос, который ведет себя как функция ...

Как и в предыдущем случае, это не ответ, а комментарий. По теме: вот почему вы используете материал только один раз: do { int macroname_i = (i); f(macroname_i); g(macroname_i); } while (/* CONSTCOND */ 0)

спасибо, поскольку оператор запятой не гарантирует порядок выполнения, это вложение - способ обеспечить это.

@Marius: Ложь; оператор запятой является точкой последовательности и, таким образом, делает гарантирует порядок выполнения. Я подозреваю, что вы перепутали его с запятой в списках аргументов функций.

Второе экзотическое предложение сделало мой день лучше.

Просто хотел добавить, что компиляторы вынуждены сохранять наблюдаемое поведение программы, поэтому оптимизация do / while away не имеет большого значения (при условии, что оптимизация компилятора верна).

@MarcoA. хотя вы правы, в прошлом я обнаружил, что оптимизация компилятора, точно сохраняя функцию кода, но изменяя строки, которые, казалось бы, ничего не делали в единственном контексте, нарушает многопоточные алгоритмы. Речь идет о пункте Peterson's Algorithm.

Это также не будет работать для всех видов конструкций, хотя C с тернарным оператором и this довольно выразителен.

Обычно в макросах добавляются символы подчеркивания в имена переменных, например int __i;.

@Blaisorblade: На самом деле это неверно и незаконно C; ведущие подчеркивания зарезервированы для использования реализацией. Причина, по которой вы видели этот «обычный шаблон», - это чтение системных заголовков («реализация»), которые должны ограничиваться этим зарезервированным пространством имен. Для приложений / библиотек вы должны выбрать свои собственные непонятные, маловероятные имена без подчеркивания, например mylib_internal___i или аналогичный.

@R .. Вы правы - я на самом деле читал это в "приложении", ядре Linux, но в любом случае это исключение, поскольку оно не использует стандартную библиотеку (технически, вместо этого, "автономная" реализация C "размещенного").

@R .. это не совсем правильно: начальные подчеркивания с последующим заглавным или вторым подчеркиванием зарезервированы для реализации во всех контекстах. Начальные подчеркивания, за которыми следует что-то еще, не зарезервированы в локальной области.

@Leushenko: Да, но различие достаточно тонкое, и я считаю, что лучше всего сказать людям, чтобы они вообще не использовали такие имена. Люди, которые понимают эту тонкость, вероятно, уже знают, что я замалчиваю детали. :-)

Хотя это правильно, это не ответ на вопрос. По правилам сайта, пожалуйста, сделайте это в комментарии; если вы не можете, сначала соберите карму из хороших ответов (которые на самом деле являются ответами); да, первые шаги могут быть трудными, но в SO все это возможно.

вот почему вы должны сделать #define FOO(X) if (1) { f(X); g(X); } else (void)0

@RichardHansen: Все еще не так хорошо, потому что, глядя на вызов макроса, вы не знаете, расширяется ли он до оператора или до выражения. Если кто-то предположит позднее, он может написать FOO(1),x++;, что снова даст нам ложное срабатывание. Просто используйте do ... while и все.

Чтобы избежать недоразумений, достаточно документировать макрос. Я согласен с тем, что do ... while (0) предпочтительнее, но у него есть один недостаток: break или continue будут управлять циклом do ... while (0), а не циклом, содержащим вызов макроса. Так что трюк с if все еще имеет значение.

Я не понимаю, где вы могли бы разместить break или continue, которые будут видны внутри вашего псевдопетля макроса do {...} while(0). Даже в параметре макроса будет синтаксическая ошибка.

Другой причиной использования конструкции do { ... } while(0) вместо конструкции if whatever является ее идиоматическая природа. Конструкция do {...} while(0) широко распространена, хорошо известна и часто используется многими программистами. Его обоснование и документация известны. Не так для конструкции if. Следовательно, при проверке кода требуется меньше усилий для проверки.

@tristopia: я видел, как люди пишут макросы, которые принимают блоки кода в качестве аргументов (что я не обязательно рекомендую). Например: #define CHECK(call, onerr) if (0 != (call)) { onerr } else (void)0. Его можно использовать как CHECK(system("foo"), break;);, где break; предназначен для обозначения цикла, включающего вызов CHECK().

использование блокировки блока {} в макросе было бы достаточным для объединения кода макроса, чтобы все выполнялись для одного и того же пути if-condition. do-while around используется для установки точки с запятой в местах, где используется макрос. таким образом, макрос принудительно ведет себя подобным образом. это включает требование наличия конечной точки с запятой при использовании.

Хотя это очень умно, это приводит к тому, что компилятор забрасывает его предупреждениями о потенциальном подвешивании else.

Обычно вы используете макросы для создания замкнутой среды, то есть вы никогда не используете break (или continue) внутри макроса для управления циклом, который начался / закончился снаружи, это просто плохой стиль и скрывает потенциальные точки выхода.

В Boost также есть библиотека препроцессора. Что в этом умопомрачительного?

Риск с else ((void)0) заключается в том, что кто-то может писать YOUR_MACRO(), f();, и он будет синтаксически корректным, но никогда не вызовет f(). С dowhile это синтаксическая ошибка.

@melpomene так что насчет else do; while (0)?