Что такое макрос препроцессора NDEBUG, используемый для (на разных платформах)?
Мне интересно, в какой цели различные платформы/компиляторы ( "реализации" )/framework присваивают макросу C и С++ препроцессора NDEBUG
.
C, а также стандарт С++ упоминают это определение только один раз, а именно для управления поведением макроса assert()
.
Я бы попросил включить только конкретные ответы, в которых вы знаете, что определенная платформа/инфраструктура/библиотека для C или С++ использует определение NDEBUG
для включения или отключения чего-либо еще в дополнение к стандарту, определенному макросом assert()
.
Одна из причин, по которой задавался этот вопрос, заключалась в том, что MS (Visual-С++) всегда (?) использует "свои" _DEBUG
для определения различать материалы отладки и выпуска, и мне было интересно, является ли это обычной практикой для библиотеки/платформы для определения собственной "отладки" или используют ли другие библиотеки/платформы NDEBUG
для связанных с отладкой материалов.
Ответы
Ответ 1
Это решение до сопровождающего (-ов) рассматриваемой структуры. Поскольку такие решения могут быть изменены, вам не следует полагаться. Я использую NDEBUG в качестве переключателя для всех связанных с отладкой (например, выходов трассировки), но я могу изменить свое мнение в следующей версии. Никакой ответ, который может дать здесь, - это замена для проверки документации API фреймворков, которые вы используете в данном проекте.
Говоря об этом, использование NDEBUG в заголовках библиотеки/структуры для чего угодно, кроме assert()
, было бы довольно немым дизайнерским решением. Программисту приложений явно разрешено устанавливать/отменять NDEBUG, но он считает нужным, до и/или после включения заголовков любой библиотеки или фреймворка, поэтому сторонний разработчик lib/framework не мог полагаться на NDEBUG, устанавливаемый для выпуска lib или не установленный для отладки lib. Я сомневаюсь, что какой-нибудь значительный проект мог бы опираться на NDEBUG таким образом.
Ответ 2
Единственная "стандартная" вещь о NDEBUG
заключается в том, что она использовала для контроля того, будет ли макрос assert
расширяться во что-то, что выполняет проверку или нет. MSVC помогает определить этот макрос в конфигурациях сборки релизов, указав его в проекте для вас. Вы можете изменить это вручную, отредактировав конфигурацию проекта. Другие инструментальные средства могут (или не могут) делать что-то подобное.
Обратите внимание, что вы также можете изменить состояние макроса NDEBUG
в блоке трансляции (исходный файл) с помощью #define
и/или #undef
на NDEBUG
и повторно включить assert.h
, чтобы изменить способ assert
макрос ведет себя (включает и выключает). Это поведение задано стандартом, и это единственный раз (я думаю), когда стандарт позволяет включить стандартный заголовок второй раз, чтобы изменить поведение компиляции после второго включения.