В макросах C, должен каждый предпочитать сделать {…}, в то время как (0,0) делают {…} в то время как (0)?
Вот хорошая статья о метках Схем базы данных:
http://howto.philippkeller.com/2005/04/24/Tags-Database-schemas/
наряду с тестами производительности:
http://howto.philippkeller.com/2005/06/19/Tagsystems-performance-tests/
Примечание, что заключения там очень характерны для MySQL, который (по крайней мере, в 2005 в то время, когда был записан) имел очень плохие характеристики полнотекстового индексирования.
2 ответа
Хорошо, я отвечу:
Есть ли законная причина, по которой следует предпочесть вторую форму макроса ...?
Нет. Нет законной причины. Оба всегда имеют значение false, и любой достойный компилятор, вероятно, все равно превратит второй в первый в сборке. Если в некоторых случаях была какая-либо причина, по которой он был недействителен, C существует достаточно долго, чтобы его обнаружили более сильные гуру, чем я.
Если вам нравится, что ваш код заставляет вас смотреть на совиные глаза, используйте , а (0,0) . В противном случае используйте то, что использует весь остальной мир программирования C, и скажите инструменту статического анализа вашего клиента, чтобы он его засунул.
Просто угадайте, почему они могут предложить использовать
do { ... } while(0,0)
вместо
do { ... } while(0)
Даже при том, что нет никакой разницы в поведении и не должно быть разницы во времени выполнения между ними.
Я предполагаю, что что инструмент статического анализа жалуется на то, что цикл , в то время как управляется константой в более простом случае, и не жалуется, когда используется 0,0 . Предложение клиента, вероятно, просто для того, чтобы он не получил кучу ложных срабатываний от инструмента.
Например, я иногда сталкиваюсь с ситуациями, когда я хочу, чтобы условный оператор контролировался константой, но компилятор будет жаловаться с предупреждение об оценке условного выражения как константы. Затем мне приходится перепрыгивать через несколько обручей, чтобы компилятор перестал жаловаться (так как я не люблю ложные предупреждения).
Предложение вашего клиента - одно из средств, которые я использовал, чтобы заглушить это предупреждение, хотя в моем случае оно не управляло циклом while , оно было связано с утверждением «всегда терпит неудачу» . Иногда у меня есть область кода, которая никогда не должна выполняться (возможно, случай переключателя по умолчанию). В этой ситуации у меня могло бы быть утверждение, которое всегда терпит неудачу с некоторым сообщением:
assert( !"We should have never gotten here, dammit...");
Но, по крайней мере, один компилятор, который я использую, выдает предупреждение о том, что выражение всегда оценивается как ложное. Однако, если я изменю его на:
assert( ("We should have never gotten here, dammit...", 0));
Предупреждение исчезнет, и все будут счастливы. Я предполагаю, что даже инструмент статического анализа вашего клиента тоже подойдет. Обратите внимание, что я обычно скрываю этот небольшой прыжок за макросом, например:
#define ASSERT_FAIL( x) assert( ((x), 0))
Было бы неплохо иметь возможность сказать поставщику инструмента, чтобы он исправил проблему, но могут быть законные случаи, когда они действительно хотят диагностировать цикл, управляемый постоянным логическим выражением. Не говоря уже о том факте, что даже если вы убедите поставщика инструментов внести такое изменение, это не поможет вам в течение следующего года или около того, чтобы на самом деле получить исправление.