디버깅과 릴리스 라이브러리/바이너리 혼합 - 나쁜 습관?

Question

디버그 바이너리에서 타사 라이브러리의 릴리스 버전을 사용하는 것은 나쁜 습관입니까?

타사 라이브러리를 사용하고 릴리스 .lib 라이브러리를 컴파일했습니다. 내 exe는 디버그 모드 개발 중입니다. 내가 디버그와 릴리즈를 혼합하는 것을 시도하고 있기 때문에 즉 발견 된 일부 인터넷 검색 후

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

을, 나는 아마 디버그 모드에서 라이브러리를 컴파일하거나 그렇지 않으면 _ITERATOR_DEBUG_LEVEL 매크로와 혼란한다 : 그럼 얻었다. 그러나 그 것이 권장 된 방법이고 왜 그런지 궁금합니다. 필자가 사용하고자하는 모든 타사 라이브러리에 대한 릴리스 및 디버그 바이너리 모두를 컴파일하고 보관해야하는 번거 로움이 있습니다.이 코드로 디버깅 할 의도는 없지만 곧 많은 작업이 수행됩니다.

Answer 1

디버깅 코드와 릴리스 코드를 혼용하는 것은 좋지 않습니다. 문제는 다른 버전이 C++ 런타임 라이브러리의 다른 기본 부분에 의존 할 수 있다는 것입니다. 예를 들어 메모리가 할당되는 방식, 반복자와 같은 구조가 다를 수 있으며 작업을 수행하기 위해 추가 코드가 생성 될 수 있습니다 (예 : 반복자 검사).

다른 설정으로 빌드 된 라이브러리 파일을 혼합하는 것과 같습니다. 헤더 파일에 응용 프로그램과 라이브러리에서 사용되는 구조가 포함되어있는 경우를 생각해보십시오. 라이브러리는 구조 패킹 및 정렬을 한 값으로 설정하고 응용 프로그램을 다른 값으로 작성하여 작성됩니다. 응용 프로그램의 구조를 라이브러리로 전달하는 것이 크기와 멤버 위치가 다를 수 있기 때문에 작동한다는 보장은 없습니다.

타사 라이브러리를 DLL로 빌드 할 수 있습니까? 어떤 함수에 대한 인터페이스가 더 깔끔하고 STL 객체를 전달하려고하지 않는다면 디버그 애플리케이션을 문제없이 릴리스 DLL과 혼합 할 수 있습니다.

Answer 2

컴파일되지 않는다는 사실은 나쁜 습관임을 입증하기에 충분해야합니다.

별도의 빌드 유지에 관해서는 그렇게하지 않아도됩니다. 이전에 나를 위해 일한 해결 방법은 다음과 같습니다.

#ifdef _DEBUG 
#define DEBUG_WAS_DEFINED 
#undef _DEBUG 
#endif 

#include <culprit> 

#ifdef DEBUG_WAS_DEFINED 
#define _DEBUG 
#endif 

이 기능이 작동하는지 알려주세요.