Visual C ++ - зачем работать в режиме отладки?

Question

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

1. Разве режим отладки не помогает вам находить ошибки?
2. Зачем беспокоиться о режиме отладки, если он позволяет ошибкам ускользать от вас?

Любой совет?

Answer 1

На самом деле не существует такой вещи, как режим выпуска или режим отладки. Есть только разные конфигурации с разными опциями. Выпуск 'mode' и Debug 'mode' - это обычные конфигурации.

Что вы сделали, так это изменили конфигурацию выпуска, чтобы включить некоторые опции, которые обычно включены в конфигурации отладки.

Включение этих параметров делает двоичные файлы больше и медленнее, в зависимости от того, какие из них вы включаете.

Чем больше этих опций вы включите, тем легче будет находить ошибки. Я думаю, что ваш вопрос должен звучать так: "Зачем беспокоиться о режиме релиза?" Ответ в том, что он меньше и быстрее.

Answer 2

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

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

Кроме того, многие средства отладки, такие как assert, полагаются на NDEBUG, который не определен, как в случае отладочных сборок, но не по умолчанию в сборках выпуска.

Answer 3

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

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

Answer 4

Оптимизация будет отключена, что облегчает отладку (в противном случае код может быть переупорядочен странным образом). Также может быть включен условный код, такой как assert () и т. Д.

Answer 5

Включение полных символов в ваше приложение включает важную информацию о сборочном компьютере (пути и т. Д. Встроены).

Рекомендуется включать символы «Только для PDB» в сборки выпуска (не включая символы файлов, строк и локальных переменных) с включенной оптимизацией. И отладочная сборка не имеет оптимизации и полных символов.

И (как отмечено в другом ответе) исключение общего подвыражения и переупорядочение инструкций могут сделать отладку интересной (переход далее идет к строкам n, n + 2, n + 1 ...). 1007 *

Answer 6

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

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

Теперь, чтобы ответить на ваши вопросы напрямую:

1. В режиме отладки есть и другие вещи, например assert() s, которые удаляются в режиме выпуска.
2. Даже если вы выполните все тестирование в режиме выпуска, ошибки все равно будут появляться. На самом деле, некоторые ошибки (например, ошибка volatile) скрыты только в режиме отладки: они все еще существуют, их сложнее вызвать.

Answer 7

оптимизация - это кошмар для отладки. Однажды у меня было приложение с этим для цикла

for (int i = 0; i < 10; i++)
{
  //use i with something
}

я всегда был 0 при отладке. но вывод его на консоль показал, что он увеличился