Какой препроцессор следует определять для указания разделов отладки кода?
Используйте #ifdef _DEBUG или #ifndef NDEBUG, или есть лучший способ сделать это, например. #define MY_DEBUG?
Я думаю, что _DEBUG является специфичным для Visual Studio, является стандартом NDEBUG?
Visual Studio определяет _DEBUG когда вы указываете параметр /MTd или /MDd, NDEBUG отключает утверждения стандарта C. Используйте их при необходимости, то есть _DEBUG если вы хотите, чтобы ваш код отладки соответствовал методам отладки MS CRT, и NDEBUG если вы хотите быть совместимым с assert().
Если вы определяете свои собственные отладочные макросы (и вы не взламываете компилятор или среду выполнения C), избегайте начинать имена с подчеркивания, так как они зарезервированы.
Я полагаюсь на NDEBUG, потому что это единственный, поведение которого стандартизировано для всех компиляторов и реализаций (см. документацию для стандартного макроса assert). Отрицательная логика - небольшая скорость чтения, но это обычная идиома, с которой вы можете быстро адаптироваться.
Чтобы полагаться на что-то вроде _DEBUG, было бы полагаться на деталь реализации конкретной реализации компилятора и библиотеки. Другие компиляторы могут или не могут выбирать одно и то же соглашение.
Третий вариант - определить свой собственный макрос для вашего проекта, что вполне разумно. Наличие собственного макроса обеспечивает переносимость между реализациями и позволяет включать или отключать код отладки независимо от утверждений. Хотя, в общем, я советую не иметь разные классы отладочной информации, которые включены во время компиляции, так как это приводит к увеличению количества конфигураций, которые вы должны построить (и проверить), возможно, для небольшой выгоды.
При любом из этих параметров, если вы используете сторонний код как часть своего проекта, вам нужно знать, какое соглашение он использует.
Стандарт NDEBUG?
Да, это стандартный макрос с семантическим "Not Debug" для C89, C99, С++ 98, С++ 2003, С++ 2011, С++ 2014. В стандартах нет макросов _DEBUG.
Стандарт С++ 2003 отправляет читателя на странице "326" в разделе "17.4.2.1 Заголовки" к стандарту C.
То, что NDEBUG аналогично, Это совпадает с библиотекой Standard C.
В C89 (программисты C назвали этот стандарт стандартом C) в разделе "4.2 ДИАГНОСТИКА" было сказано
http://port70.net/~nsz/c/c89/c89-draft.html
Если NDEBUG определяется как имя макроса в точке исходного файла где включено, макрос assert определяется просто как
#define assert(ignore) ((void)0)
Посмотрите на значение макросов _DEBUG в Visual Studio
https://msdn.microsoft.com/en-us/library/b0084kay.aspx
то будет видно, что этот макрос автоматически определяется вашим выбором версии библиотеки языка исполнения.
Макрос NDEBUG контролирует, являются ли операторы assert() активными или нет.
На мой взгляд, это отдельно от любой другой отладки - поэтому я использую что-то другое, кроме NDEBUG, для управления информацией отладки в программе. То, что я использую, зависит от структуры, с которой я работаю; разные системы имеют разные макросы включения, и я использую все, что подходит.
Если нет рамки, я бы использовал имя без главного подчеркивания; те, как правило, зарезервированы для "реализации", и я стараюсь избегать проблем с именами совпадений - вдвойне, когда имя является макросом.
Будьте последовательны, и неважно, какой из них. Также, если по какой-то причине вы должны взаимодействовать с другой программой или инструментом, используя определенный идентификатор DEBUG, легко выполнить
#ifdef THEIRDEBUG
#define MYDEBUG
#endif //and vice-versa
К сожалению, "DEBUG" сильно перегружен. Например, рекомендуется всегда генерировать и сохранять файл pdb для сборки RELEASE. Это означает, что один из флагов -Zx и опция -DEBUG-компоновщик. В то время как _DEBUG относится к специальным версиям отладки библиотеки времени выполнения, таким как звонки в malloc и бесплатно. Затем NDEBUG отключит утверждения.