MSVC, смешивающий код отладки с кодом выпуска - PullRequest
Новая
       32

MSVC, смешивающий код отладки с кодом выпуска

3 голосов
/ 09 ноября 2010

Мотивация для вопроса : для генерации 64-битного и 32-битного кода требуются две отдельные полные программные компиляции, а при использовании Visual Studio (как подробно описано ниже) сборки выпуска и отладки несовместимы, поэтому, по-видимому, они кажутся несовместимыми. требуются еще две полные программы-компиляции (доведя общее количество до четырех). Я хотел бы придерживаться двух полных программных компиляций, но я в замешательстве.

При отладке все, что меня волнует: глобальное состояние, кадр стека и номер строки / файла кода, вызвавшего сбой. Кроме того, мне нет дела до отладочной информации из проверенных высокостабильных библиотек с открытым исходным кодом; поэтому мне не нужна информация отладки для этих библиотек, и сборка выпуска для этих библиотек должна быть адекватной.

Свидетельство: Я знаю, что в VS, если вы скомпилируете отладочную версию приложения и свяжете ее с версией выпуска буферов протокола Google, созданный код потерпит неудачу из-за побочного эффекта смешивания типов выпуска / отладки.

Я хотел бы знать, является ли это побочным эффектом использования visual studio, и определенный набор переключателей компилятора делает это так.

Во-вторых, при проверке сценариев / процессов сборки проектов с открытым исходным кодом кажется, что можно смешивать код, сгенерированный в режиме отладки, с кодом, сгенерированным в релизе (например, mumble ). Я предполагаю, что это как-то связано с различием между release и ReleaseWithDebugInfo (термин заимствован из cmake, но это, очевидно, можно выразить в Visual Studio). ReleaseWithDebugInfo - это, в конце концов, оптимизированная версия двоичного файла, также сгенерированная отладочная информация, и, следовательно, подходящая для выпуска.

Вопросы:

  1. Может, кто-нибудь объяснит или предоставит ссылки на то, какие переключатели делают код несовместимым.
  2. Достаточно ли стиля компиляции ReleaseWithDebugInfo в visual studio для сценариев отладки и выпуска (в соответствии с моими критериями, как описано выше)? - То есть, что генерирует компилятор в режиме отладки - избыточное или избыточное?
  3. В режиме ReleaseWithDebugInfo (для моего приложения) я могу скомпилировать внешние зависимости в режиме выпуска (без отладочной информации) и не иметь неопределенного поведения?

1 Ответ

4 голосов
/ 09 ноября 2010

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

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

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

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

Обычная проблема со связыванием разных конфигураций - это когда они совместно используют объекты, выделенные разными версиями / конфигурациями библиотек времени выполнения. Если вы используете интерфейс между библиотеками в стиле «C» в стиле Win32, то вам редко нужно заботиться о том, отлажены ли они, а какие - нет. Если вы выделяете строку CString в куче с одной версией среды выполнения, а затем передаете ее в код, который освобождает от другой среды выполнения, то часто возникают проблемы.

Здесь нужно подумать о трех разных вещах:

  • Нужны ли символы отладки? - Вы можете сделать это в любой конфигурации отладки / выпуска
  • Нужна ли мне хорошая отладка или хорошая оптимизация кода?
  • Какую CRT / STL / какую версию используют все?

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

...