Имеет ли место быть использование кодогерерирующих макросов для Debug версии приложения, а на Realise их отсутствие?

Question

[Acaunt]

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

#define DEBUG true

#if DEBUG

#define COMMA ,
#define LOCATION(name) const std::source_location& name = std::source_location::current()
#define PARAMETER(name) name

#else

#define COMMA
#define LOCATION(name)
#define PARAMETER(name)

#endif

void foo(int value COMMA LOCATION(loc)) {
    static constexpr std::string_view message = DEBUG ? "value = {} In [{}, {}] file: {}" : "value = {}";
    std::println(
        message,
        value COMMA
        PARAMETER(loc.line()) COMMA
        PARAMETER(loc.column()) COMMA
        PARAMETER(loc.file_name())
    );
}

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

Comments

[VoidVolker]

Acaunt а в чём у вас собственно вопрос-то?

[Acaunt]

VoidVolker, Да это не совсем вопрос, просто чужое мнение хотелось бы выслушать по такому поводу. Может кто-нибудь подобное уже делал. Там могут ли проблемы какие-нибудь возникнуть. Я пробовал это обсуждать с нейросетями, но у них это впринципе зашито то что макросы это зло, хотя если спросить как добиться подобного эффекта то они подобный код и выдадут со словами пользуйтесь спокойно.

[VoidVolker]

Acaunt,

просто чужое мнение хотелось бы выслушать по такому поводу

В этом случае ваш вопрос попадает под определение "опрос" и нарушает правила: https://qna.habr.com/help/rules#5.11

Может кто-нибудь подобное уже делал.

Вообще-то, это стандартная практика. В отладочной версии всегда будут дополнительные функции и вызовы для целей отладки, а в релизной оно естественно всё вырезается за ненадобностью.

[Acaunt]

VoidVolker, ну да понимал что нарушаю правила, просто без понятия где вообще такое обсуждать

Answer 1

[Пума Тайланд]

Не меняй макросами сигнатуру foo() — оберни макросом только вызов лога

Comments

[Acaunt]

Например как? Я просто подобное ещё хотел использовать для генераторов исключений

[Пума Тайланд]

Acaunt, тем же приёмом: под DEBUG throw добавляет в текст исключения file/line из source_location, под Release кидает то же исключение без этих деталей — сигнатуру фабрики исключений не трогаем, макросом оборачиваем только сам throw.

Answer 2

[Zerg89]

По идее при компиляции достаточно сделать define DEBUG false и выставить оптимизацию кода даже на минимальный уровень и это будет удалено компилятором так как будет считатся неисполняемой функцией

Еще вариантconstexpr bool DEBUG = false чтобы при компиляции было четко предопрделено что функция не может быть исполнена

Офтоп хотя может наоборот стоить это оставить чтобы дебажить уже скомпилированный код

Comments

[Acaunt]

Я знаю что при релизе нужно сделать DEBUG false я это заранее продумал

И я пробовал так делать используя константу, но тогда все COMMA, LOCATION, PARAMETER они работать не будут и компилятор будет жаловаться на это всё. Ведь сперва компилируются макросы, а уже потом константы

Answer 3

[res2001]

На счет макроса DEBUG - все уже придумано до нас :)
Есть стандартный макрос NDEBUG. Его добавляет компилятор к release сборке и удаляет в debug, т.е. действие обратное вашему, но смысл тот же. Только с ним нюанс - он обычно значения не имеет, поэтому его надо проверять на #ifdef/#ifndef.
Так же есть чудесное средство assert, которые работают только в debug сборке - можно проверять различные условия, инварианты, на входе в функции и т.п. Крайне рекомендую. В релизе все assertы удаляются. Если посмотреть как они определены в стандартной библиотеке, то там обычно используется макрос NDEBUG.
И да, изменять макросами сигнатуру функции - так себе идея, я бы не делал.

Comments

[Acaunt]

Использование ifdef не всегда уместно. И иногда нужно логическое значение для программы например подобное:

using iterator = std::conditional_t<DEBUG, Debug_iteratot, pointer>

Ну это например хотя да можно просто через ifdef, но кажется не всегда удобно для понимания, а тут как-то явнее.

И иногда нужно именно добавить функциональности или немного изменить структуру кода без вреда на итоговый результат кода хоть в debug хоть в release

Про assert я слышал, но как-то ещё не приходилось использовать. Он проверяет условие на истинность вроде и если ложно то вырубает программу насколько мне это известно, но это не совсем то. Все таки хочется обработать как-нибудь ошибку

[res2001]

Acaunt, Это уже нюансы.
Я имел ввиду, что сам механизм уже есть, причем он стандартизирован (правда в Си, но и в плюсах его вполне можно использовать). На его основе вы можете сделать свой макрос или constexpr, содержащий логическое значение:

#ifndef NDEBUG
constexpr bool DEBUG = true;
#else
constexpr bool DEBUG = false;
#endif

И далее уже использовать этот DEBUG, причем следить за правильностью его настройки в системе сборки уже не надо.
assert - к теме вопроса отношения не имеет, но на прямую имеет отношение к NDEBUG да и вообще инструмент полезный, многие его игнорируют, но я использую практически в каждой функции/методе. Если правильно расставить в ассерте инварианты на входе в функцию, то заметно облегчает отладку кода в случае возникновения ошибок. Кроме того, ассертом вы показываете читающему код коллеге какое состояние ожидает функция на входе.

Answer 4

[Wataru]

Имеет. Так, например, в хромиуме делается отладочный вывод: https://source.chromium.org/chromium/chromium/src/...

Он правда сильно усложнен по сравнению с вашим, но умеет сильно больше чего.
Используется как обычный cerr, но в релизе вообще ничгео не делает и компилятор его вообще за ненадобностью вырезает.

А еще есть DCHECK - для ассертов, которые не надо в релизный билд компилировать: https://source.chromium.org/chromium/chromium/src/...