В чем причина использования макроса DEBUG в C++?

Question

Я работаю на C++ программа построена другими людьми, и видел много использования DEBUG как этот

#ifdef DEBUG 
    cout << "Value is "<< value << endl; 
#endif 

Я сам до сих пор в процессе обучения, чтобы стать богатым C++ программист, и я главно использование Visual Studio и точки останова для отладки. Поэтому мне интересно, если я смогу выполнить код для отладки значений, есть ли другая причина использовать эти макросы?

Пробовал Google, но не нашел много полезной страницы.

Спасибо.

Answer 1

Иногда вы не хотите проходить весь код, а просто проверяете вывод в терминале.

Если код скомпилирован с DEBUG, определенным, вероятно, в сборке отладки, вы видите результат. Для сборки релиза вы этого не делаете. Если вы перейдете на параметры проекта -> Свойства конфигурации -> C/C++ -> Препроцессор -> Определения препроцессора, вы увидите, что для сборки отладки определен DEBUG, но это не для выпуска. (У меня действительно есть _DEBUG)

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

Answer 2

Это для отладки, обернув код в командах препроцессора, вы можете включить или выключить этот код.

Посмотрите здесь: C++ Notes: Preprocessor

Answer 3

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

Необходимость «отладки текстового режима» и ведения журналов также часто происходит из опыта встроенных систем, где у вас нет большой наглядной помощи, и все, что вы можете сделать, это сбросить байт или два в последовательный порт или что-то еще как это. Когда вы привыкнете быстро находить критические точки отладки, вы просто вставляете там какой-то код печати, чье значение проверяет правильность программы.

Макрос «DEBUG» определяется компилятором MSVC++, в то время как ваш проект скомпилирован в режиме отладки. Когда вы делаете версию Release, весь код, который на самом деле бесполезен для конечных пользователей, «убирается» препроцессором.

Типичный фрагмент

#ifdef DEBUG 
Some code 
#endif 

удаляется препроцессором, если ОТЛАДКА не определен.

Answer 4

Легко, если вы хотите получить сообщения, которые могут помочь вам сделать «мягкий» отладчик, вы просто определяете DEBUG, и предложения между #ifdef DEBUG и #endif будут иметь эффект, а в вашем случае получите полезные сообщения.

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

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

Answer 5

«Я главно использовать Visual Studio и точки останова для отладки»
Отладка кода, наблюдая за его поведением шаг за шагом довольно трудно или даже невозможно в некоторых ситуациях. Иногда проще создать такой «отладочный вывод», чтобы вы видели, что происходит из этих журналов, вместо того, чтобы пытаться пройти через него в реальном времени.

Проверка того, установлен ли символ DEBUG, чтобы убедиться, что ваша версия выпуска не производит такой вид вывода. Обратите внимание, что Visual Studio определяет _DEBUG для конфигурации отладки. Более конкретно: «Компилятор определяет _DEBUG, когда вы указываете параметр/MTd или/MDd. Эти параметры определяют версии отладки библиотеки времени выполнения C». Существует также NDEBUG, который отключает утверждения стиля C, если они определены. Для получения дополнительной информации проверьте _DEBUG vs NDEBUG.

Answer 6

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

Answer 7

Я бы рекомендовал не использовать макрос DEBUG. Вместо этого используйте стандартный макрос NDEBUG, который определяется, когда код отладки не нужен, а не определен, когда требуется отладочный код. То есть, отлаживать код активным по умолчанию. Вы обнаружите, что только небольшое ядро ​​критически важного кода производительности должно отключать отладочные проверки для обеспечения адекватной производительности.