Смешивание отладки и выпуска библиотеки/двоичного кода - неправильная практика?

Неправильно ли использовать версию debend-библиотеки сторонних разработчиков в debug-двоичном формате?

Я использую стороннюю библиотеку и скомпилировал библиотеку lib. Мой exe работает в режиме отладки. Затем я получил:

error LNK2038: mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '0' doesn't match value '2' in test1.obj

После некоторого googling я обнаружил, что это потому, что я пытаюсь смешивать выпуск с debug, и я должен, вероятно, скомпилировать библиотеку в режиме отладки или иным образом запутать макрос _ITERATOR_DEBUG_LEVEL. Но мне просто интересно, если это рекомендуемый способ и почему. Просто кажется громоздким, что мне нужно скомпилировать и сохранить записи как для релизов, так и для отладочных двоичных файлов для каждой сторонней библиотеки, которую я намерен использовать, что будет очень скоро, не имея намерения отлаживать этот код.

Ответ 1

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

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

Возможно ли построить ваши сторонние библиотеки как библиотеки DLL? Предполагая, что интерфейс для любых функций более чист и не пытается передать какие-либо объекты STL, вы сможете без проблем запускать приложение для отладки с выпуском DLL.

Ответ 2

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

Что касается поддержки отдельных сборок - вам не нужно это делать. Вот обходной путь, который раньше работал у меня:

#ifdef _DEBUG
#define DEBUG_WAS_DEFINED
#undef _DEBUG
#endif

#include <culprit>

#ifdef DEBUG_WAS_DEFINED
#define _DEBUG
#endif

Сообщите мне, если это сработает для вас.

Ответ 3

  <UndefinePreprocessorDefinitions>_DEBUG</UndefinePreprocessorDefinitions>

решить вашу проблему