C++ STL 컨테이너 DLL 경계에서의 CRT 호환 문제

Question

안녕하세요,현재 C++로 DLL을 개발하는 중인데 배포된 DLL 코드를 들여다보지 못하도록release mode에서 빌드된 DLL만을 배포하고 있습니다.문제는 빌드된 DLL을 사용하는 측에서는 자신들의 프로그램 디버깅을 위해 debug mode로도빌드를 한다는 것인데, 이때 DLL 인터페이스에 STL 컨테이너가 존재하면 CRT 호환 문제에 의해비정상적인 동작을 한다는 것입니다.그래서 당장은 C-style로 배열의 포인터와 배열의 크기를 각각 전달하게끔 하고 있는데보통은 이렇게 C-style로 작성하는지, 아니면 vector에 대한 wrapper를 만드는지다른분들의 방식이 궁금해서 질문 남깁니다.

allinux · Answer

그 DLL 을 다른 언어에서 호출할 가능성은 없나요?보통은 다른언어에서 사용 호환성(타입이나 name mangling등) 때문에 타입 맞추고 extern "C" 로 내보냅니다.

캐티 · Answer

DLL 경계를 넘어 CRT 개체를 전달할 때 발생할 수 있는 오류 | Microsoft Learn이거 했다는 얘기이나요.일반적으로 main(exe) 에서 shared(dll)에 함수를 실행할 거이고, 특수한 객체를 넘기지 아니하였다면 잘 작동할거여요. 머를 잘못 하였게쩌.int[] array = { 1, 2, 3, 4 }이런 정적 자료형은 컴파일러가 크기를 알고 있어서 이케이케 계산되어져 빌드되지만, 상대가 공용 라이브러리에서 이 값을 가져와서 사용하지 못할거빈다.

삽살개발 · Answer

릴리즈 모드 빌드는 디버그빌드랑 뭐가 다른가요

구운개발 · Answer

저도 궁금해서 질문해본걸 남겨 봐요생각보다 차이가 좀 있군요사용처의 방식도 잘 이해하는것도 중요한것 같네요저는 핌플 패턴을 많이 봤는데 이런 이유도 있는거 같군요🔧 릴리즈 빌드 vs 디버그 빌드 차이릴리즈(Release)와 디버그(Debug) 모드의 가장 큰 차이는 다음과 같습니다:1. 최적화(Optimization)릴리즈 모드: 성능 위주 최적화가 적용되어 불필요한 코드 제거, 루프 언롤링, 인라인 확장 등의 처리가 이루어집니다.디버그 모드: 디버깅이 가능하도록 최적화가 꺼져 있고, 변수 정보, 디버깅 심볼이 포함됩니다.2. CRT (C Runtime Library)의 차이디버그와 릴리즈 빌드는 서로 다른 CRT 런타임 라이브러리를 사용합니다:Debug: MSVCRTD.lib, ucrtd.libRelease: MSVCRT.lib, ucrt.lib이 둘은 내부적으로 메모리 할당 방식, 디버그 힙 구조 등이 다르며 메모리 소유권이 교차되면 충돌 위험이 생깁니다.3. STL 구현체의 차이디버그 모드에서는 iterator 검증, boundary check, debug allocator 등 부가 기능이 포함되어 STL 컨테이너의 바이너리 구조가 바뀝니다.따라서 debug 빌드의 std::vector와 release 빌드의 std::vector는 이진호환되지 않습니다.💣 DLL 인터페이스에서 STL 컨테이너를 쓰면 안 되는 이유DLL의 인터페이스에 std::vector, std::string 같은 STL 컨테이너를 포함하면 다음 문제가 발생할 수 있습니다:CRT 불일치 문제호출자와 DLL이 서로 다른 CRT를 쓰면 new/delete, malloc/free 쌍이 일치하지 않아 메모리 충돌 발생.STL ABI 호환성디버그/릴리즈에서 STL 컨테이너의 내부 구조가 달라, 메모리 오염, 크래시 등의 문제가 발생.버전 의존성컴파일러 버전이 다르면 STL ABI가 다르고, ABI가 다르면 DLL-EXE 간 바이너리 호환이 깨짐.✅ 일반적인 해결 방안1. C 스타일 인터페이스 사용 (추천)cppコピーする編集する// DLL 쪽 extern "C" __declspec(dllexport) void GetData(int** data, int* length);구조체 또는 배열 포인터와 크기를 함께 전달.호스트와의 CRT 의존성 제거.2. Opaque Handle 사용cppコピーする編集するtypedef void* MyHandle; extern "C" __declspec(dllexport) MyHandle CreateData(); extern "C" __declspec(dllexport) void DestroyData(MyHandle handle); extern "C" __declspec(dllexport) void GetElement(MyHandle handle, int index);내부 구현은 STL을 쓰되 외부에는 정보 노출 없이 opaque handle로 캡슐화.3. PImpl(Private Implementation) + Wrapper헤더에는 STL을 숨기고, 구현부에서만 사용.🧰 vector에 대한 wrapper를 만드는 건 어떨까?std::vector<T>를 wrapping한 MyVector 클래스를 만들어 DLL 안에서만 사용하고,외부에는 인덱싱 및 크기 확인 함수 등만 제공.이 경우에도 DLL 바깥에서는 내부 메모리에 직접 접근하지 않도록 해야 하며, 메모리는 생성한 측이 해제하는 원칙을 지켜야 합니다.✍️ 정리: 어떤 방식이 적절한가요?방법안전성편의성추천도C-style 배열매우 높음낮음⭐⭐⭐⭐Opaque handle 방식높음중간⭐⭐⭐⭐vector wrapper보통높음⭐⭐STL 직접 노출낮음높음❌✅ 결론DLL 인터페이스에는 STL 컨테이너를 직접 사용하지 마세요.C-style 배열 또는 opaque 핸들을 사용하는 방식이 가장 호환성과 안정성이 좋습니다.디버깅 시에도 문제가 없으며 CRT 충돌이나 ABI 차이에서 자유로울 수 있습니다.필요하시면 wrapper 예제나 더 구체적인 설계를 도와드릴 수 있습니다!

C++ STL 컨테이너 DLL 경계에서의 CRT 호환 문제

4개의 답변

#dll 목록