Обсуждение: JTN002 - MinUnit -- a minimal unit testing framework for C

[Алексей++]

https://forum.shelek.ru/index.php/topic,28557.msg299437.html#msg299437

Dale, так почему он настаивает на использовании

do {} while(0)

вместо обычных

{}

- я так и не понял )  По ссылке тоже не нашёл объяснения, почему именно в виде цикла. Не, я понимаю, что из-за нуля это такие же скобки, но тем не менее - почему настаивается на цикле ?

Разве что защита от "случайного" попадания внутрь макроса continue или break - но это каким надо быть криворуким, чтобы так произошло


А сам макрос я бы спроектировал так, чтобы список тестов выглядел так

Код:

 static char* all_tests()
{
     mu_run_test(test_foo,"error, foo != 7", foo == 7);
     mu_run_test(test_bar,"error, bar != 5", bar == 5);
     return 0;
}

[darkelf]

Dale, так почему он настаивает на использовании

do {} while(0)

вместо обычных

{}

- я так и не понял )  По ссылке тоже не нашёл объяснения, почему именно в виде цикла. Не, я понимаю, что из-за нуля это такие же скобки, но тем не менее - почему настаивается на цикле ?

Я так понял, потому-что после while (0) надо обязательно ставить ';', и если его не будет, то будет ошибка компиляции, а если пропустить ';' после {} - компилятор ничего не скажет.

[zubr]

Использование одноразового цикла, имхо, удобно как раз с использованием continue, break вместо порой громоздких вложенных if

[Dale]

Dale, так почему он настаивает на использовании

do {} while(0)

вместо обычных

{}

- я так и не понял )  По ссылке тоже не нашёл объяснения, почему именно в виде цикла. Не, я понимаю, что из-за нуля это такие же скобки, но тем не менее - почему настаивается на цикле ?

Эта очень неуклюжая для чтения конструкция служит единственной цели - превратить макрос, содержащий несколько операторов, в простой оператор (фигурные скобки дают составной, и это иногда может быть проблемой). Такая идиома позволяет безопасно использовать макрос практически в любом контексте.

Пример: условный оператор выглядит так

Код: (C)

if (condition)
  stmt1;
else
  stmt2;

Если в качестве stmt1 использовать макрос, который раскрывается фигурными скобками, получим нечто вроде:

Код: (C)

if (condition)
  {
    ....
  };
else
  stmt2;

, что является синтаксической ошибкой. В случае "одноразового" цикла то же самое выглядит так:

Код: (C)

if (condition)
  do {
    ....
  } while (0);
else
  stmt2;

Это позволяет использовать макрос не только изолированно, но и в контексте условных операторов, циклов etc.

Кстати, как-то я высказал мнение (подкрепленное цитатой из Страуструпа), с которым не все согласились, что макрос - довольно проблемная конструкция, и по возможности следует обходиться другими средствами (благо в C++ без использования макросов можно обойтись почти всегда). Это - одна из многих иллюстраций подобных проблем. Они, конечно, решаемы, но отнюдь не изящно.

А сам макрос я бы спроектировал так, чтобы список тестов выглядел так

Во-первых, в модульном тестировании сложились определенные устои; например, тест должен быть самодостаточным, т.е. должно быть достаточно прочитать исходник test_foo, чтобы понять, что он тестирует, а не искать параметры его вызова. Но это лишь вопрос вкуса и привычек.

Во-вторых, что более существенно, в одном тесте может быть несколько ассертов. Тогда придется формировать в макросе список условий проверки и список сообщений об ошибках, да еще и следить, чтобы списки соответствовали друг другу. IMHO лишний геморрой, не способствующий ни удобству при написании тестов, ни легкости их чтения (не говоря о том, что проблемно написать поясняющие комментарии). Не забываем, что тесты - это еще и документация, причем не в последнюю очередь!

[Алексей++]

Dale, понятно теперь

Я макросы тоже не люблю использовать, но иногда бывает, что они нужны. Ооочень редко

[Aether]

Кстати, как-то я высказал мнение (подкрепленное цитатой из Страуструпа), с которым не все согласились, что макрос - довольно проблемная конструкция, и по возможности следует обходиться другими средствами (благо в C++ без использования макросов можно обойтись почти всегда). Это - одна из многих иллюстраций подобных проблем. Они, конечно, решаемы, но отнюдь не изящно.

Я макросы тоже не люблю использовать, но иногда бывает, что они нужны. Ооочень редко

Почему в С++ можно обойтись без макросов, а в С нет? По мне, сложные макросы вносят путаницу, чаще проще написать отдельную программу для подсчёта, например, таблицы инволюты, чтобы потом присоединить её к целевому проекту, нежели сочинять весьма непростые для стороннего понимания конструкции генерирования этих таблиц при помощи макросов.

[Dale]

Я макросы тоже не люблю использовать, но иногда бывает, что они нужны. Ооочень редко

К счастью, в C++ они действительно требуются очень редко (тем, кто реально знает и понимает, зачем добавили пару плюсов), а в более современных языках и вообще отсутствуют. К несчастью, в старом добром C макросы совершенно необходимы для нетривиальных программ, и с ними приходится мириться. Например, посмотрите реализацию CException или Protothreads, там они буквально на каждом шагу.

Почему в С++ можно обойтись без макросов, а в С нет?

Как заметил Алексей++, "они нужны. Ооочень редко"(С). Давайте разберем несколько типичных случаев использования макросов и решим, нужны они реально или нет.

1. Защита заголовочных файлов от множественных включений:

Код: (C)

#ifndef MYHEADER_H
#define MYHEADER_H
.
.
.
#endif

В различных реализациях компиляторов имеются прагмы, которые препятствуют повторному включению заголовка при обработке препроцессором (нечто вроде #pragma once), но они не портабельны, как и полагается прагмам. В данном случае использование макроса вполне оправданно, поскольку правильно работает на любой платформе. К тому же идиома давно устоялась и вызовет недоумения разве что у самого зеленого новичка.

2. Определение констант:

Код: (C)

#define PI 3.1415927

Выглядит гораздо читабельнее, чем "магические числа", в изобилии разбросанные по программе, а в случае, если константу еще и потребуется переопределить, вообще единственный способ сохранить душевное здоровье программиста. Однако есть более вразумительный способ объявить константу - квалификатор const, который к тому же дает компилятору больше возможностей для оптимизации: поместить ли единственый экземпляр константы в память только для чтения и ссылаться на него, либо подставлять значение константы явно в каждой точке, где оно требуется. Препроцессор альтернатив не предоставляет.

Иногда "сишники" определяют отдельные константы через enum, но это далеко не всегда дает хороший стиль в итоге.

3. Повторяющиеся области кода:

Код: (C)

#define UGLY_MACRO { \
  a();  \
  b();  \
  c();  \
}

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

Гораздо лучше использовать спецификатор функции inline, который рекомендует компилятору вместо вызова онлайновой функции развернуть ее тело в точке вызова; впрочем, строптивый компилятор может и не послушаться, если сочтет, что для выбранного способа оптимизации вызов функции обойдется дешевле.

4. Можно приспособить макрос для генерации вариантов кода в зависимости от некоего условия (примеры приводить не буду, ибо громоздко). Гораздо лучше с этим справятся перегруженные функции, шаблоны (template), а также виртуальные методы.

Некоторые из перечисленных языковых средств имеются не только в C++, но и в поздних редакциях C (например, C99). Словом, чем дальше язык от стандарта Кернигана и Ричи, тем меньшую роль в нем играют макросы, хотя совсем на ноль все же не сходят.

По мне, сложные макросы вносят путаницу

Совершенно верно. Кроме того, их бывает трудно раскрывать в уме, чтобы понять, чем именно недоволен компилятор. А уж тестировать макросы и подавно неблагодарное занятие.

[Алексей++]

Dale, я где-то встречал мнение, что современным компиляторам C++ даже и не обязательно указывать inline, они вроде сами всегда при включенной оптимизации пытаются определить, нужно ли сделать вызов или встроить код

[RXL]

Добавлю, что макросы еще используются для переопределения функции, например для дебаговой и релизной сборки:

Код: (C++)

int _debug(char* s);

#ifdef XXX
#define debug(s) _debug(s)
#else
#define debug(s)
#endif

debug("zhopa!")

[Dale]

Dale, я где-то встречал мнение, что современным компиляторам C++ даже и не обязательно указывать inline, они вроде сами всегда при включенной оптимизации пытаются определить, нужно ли сделать вызов или встроить код

Да, спецификатор inline по мере совершенствования оптимизации становится шумовой лексемой, как, к примеру, и register. Компилятор сам догадается использовать регистр под переменную, если есть возможность; если же возможности нет, то и register в исходном тексте ни на что не повлияет. То же касается inline: как говорится, ученого учить - только портить.

Добавлю, что макросы еще используются для переопределения функции, например для дебаговой и релизной сборки

Хорошее применение макроса для C. При программировании в объектном стиле я бы предпочел использовать полиморфизм, тем более что в отладочной версии класса можно еще много полезного сделать.

[Вад]

Хорошее применение макроса для C. При программировании в объектном стиле я бы предпочел использовать полиморфизм, тем более что в отладочной версии класса можно еще много полезного сделать.

Подразумевается, что в отладочной сборке компилируется один исходник, а в релиз - другой? В противном случае, я не знаю, как в одном и том же файле определить тип сборки, совсем не трогая препроцессора.

[Dale]

Подразумевается, что в отладочной сборке компилируется один исходник, а в релиз - другой?

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

В противном случае, я не знаю, как в одном и том же файле определить тип сборки, совсем не трогая препроцессора.

Например, можно завести конфигурационную константу, которая определяет, отладочная сборка или нет. Сам метод с переменным поведением определить как-то так:

Код:

mytype foo(...)
{
  ...
  if (DEBUG)
  {
    // отладочный код
  }
  else
  {
    // продукционный код (если нужен)
  }
  ...
}

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

Это навскидку. Может, есть приемы получше. Сам я такими не пользуюсь, поскольку предпочитаю явно выполнять диагностический код в среде модульного/интеграционного тестирования, а не прятать его макросами, благо xUnit сегодня реализован практически для всех языков. IMHO так больше информации получаешь, да и в более удобной форме. После перехода на TDD не могу припомнить случая, когда реально требовалась бы отладочная версия кода, отличная от продукционной.