C ++ 11은 동적 / 공유 라이브러리 경계 사이에 std lib 객체를 전달하는 문제를 해결 했습니까? (즉, dll 등)?

C ++에 대한 나의 주요 불만 중 하나는 실제로 동적 라이브러리 (예 : dll / so) 경계 외부에서 std 라이브러리 객체를 전달하는 것이 얼마나 어렵다는 것입니다.

표준 라이브러리는 종종 헤더 전용입니다. 멋진 최적화를 수행하기에 좋습니다. 그러나 dll의 경우 std 라이브러리 컨테이너의 내부 구조 / 코드에 영향을 줄 수있는 다른 컴파일러 설정으로 빌드되는 경우가 많습니다. 예를 들어, MSVC에서 하나의 dll은 반복자 디버깅을 사용하여 빌드하고 다른 DLL은 그것을 해제하여 빌드 할 수 있습니다. 이 두 dll은 표준 컨테이너를 전달하는 데 문제가 발생할 수 있습니다. std::string내 인터페이스에 노출 되면 클라이언트가 사용하는 코드 std::string가 내 라이브러리와 정확히 일치 한다고 보장 할 수 없습니다 std::string.

이로 인해 문제, 두통 등을 디버그하기가 어렵습니다. 이러한 문제를 방지하기 위해 조직의 컴파일러 설정을 엄격하게 제어하거나 이러한 문제가없는보다 간단한 C 인터페이스를 사용합니다. 또는 클라이언트가 사용해야 할 예상 컴파일러 설정을 지정하십시오 (다른 라이브러리가 다른 컴파일러 설정을 지정하면 짜증납니다).

내 질문은 C ++ 11이 이러한 문제를 해결하기 위해 무엇을 시도했는지 여부입니다.

STL (실제로 템플릿 화 된 타사 라이브러리의 모든 것)은 모든 공용 C ++ API에서 피하는 것이 가장 좋습니다. http://www.ros.org/reps/rep-0009.html#definition 의 긴 규칙 목록을 따라 공개 C ++ API 프로그래밍을 방해하는 ABI 손상을 방지하려고합니다.

그리고 C ++ 11에 대한 대답은 아니오입니다.이 표준은 그것을 만지지 않습니다. 더 흥미로운 이유는 무엇입니까? 대답은 C ++ 17이 매우 감동적이기 때문에 C ++ 모듈을 구현하려면 템플릿을 내 보내야하고, 전체 AST를 디스크에 덤프 한 다음 clang과 같은 LLVM 유형 컴파일러가 필요합니다. 대규모 C ++ 프로젝트에서 많은 ODR 위반 사례를 처리하기 위해 발신자 종속 조회를 수행합니다. GCC 및 ELF 코드가 많이 포함되어 있습니다.

마지막으로, 많은 MSVC 증오와 친 GCC 의견이 있습니다. ELF의 GCC는 근본적으로, 그리고 틀림없이 유효하고 정확한 C ++ 코드를 생성 할 수 없습니다. ELF의 GCC는 Boost.Python을 사용하여 작성된 Python 확장을 Boost.Python을 기반으로 한 둘 이상의 확장이 Python에로드되는 경우 안전하게 Python 확장을 생성 할 수 없습니다. PE와 MachO 및 실제로 제안 된 C ++ 모듈 사양은 모두 모듈 당 기호 테이블을 사용하는 반면, 결국 C ++ 테이블 전역의 ELF는 segfault를 유발하는 ODR 위반을 방지하여 설계 할 수 없기 때문입니다. 그리고 더 많은 문제가 있습니다. 최근에 대답 한 StackOverflow를 참조하십시오.예를 들어 C ++ 예외 발생이 ELF에서 근본적으로 회복 될 수없는 경우 (예 : https://stackoverflow.com/questions/14268736/symbol-visibility-exceptions-runtime-error/14364055#14364055)

마지막 요점 : 서로 다른 STL의 상호 운용과 관련하여, 이는 많은 대기업 사용자가 일부 STL 구현에 긴밀하게 통합 된 타사 라이브러리를 혼합하려고 시도하는 데 큰 어려움입니다. 유일한 해결책은 C ++이 STL interop을 처리 할 수있는 새로운 메커니즘이며,이를 사용하는 동안 컴파일러 interop도 수정하여 MSVC, GCC 및 clang 컴파일 된 객체 파일을 혼합 할 수 있습니다. . 나는 C ++ 17 노력을보고 앞으로 몇 년 안에 무엇이 나올지 볼 것입니다. 아무것도하지 않으면 놀랐습니다.

사양에는이 문제가 없었습니다. 그 이유는 "하나의 정의 규칙"이라는 개념을 가지고 있기 때문입니다.이 개념은 각 심볼이 실행중인 프로세스에서 정확히 하나의 정의를 갖도록 요구합니다.

Windows DLL은이 요구 사항을 위반합니다. 그렇기 때문에 이러한 모든 문제가 있습니다. 따라서 C ++ 표준화위원회가 아니라 문제를 해결하는 것은 Microsoft의 책임입니다. 공유 라이브러리는 다르게 작동하고 기본적으로 하나의 정의 규칙을 준수하기 때문에 Unix는이 문제를 겪지 않았습니다.

Windows DLL은 다음과 같은 이유로 하나의 정의 규칙을 위반합니다.

• 정적 링크 시간 동안 어떤 동적 라이브러리에서 심볼을 사용할지 하드 코딩하고이를 정의하는 라이브러리 내에서 심볼을 정적으로 확인합니다. 따라서 단일 프로세스에서 사용되는 것보다 동일한 약한 심볼이 여러 공유 라이브러리 및 해당 라이브러리에서 생성되면 동적 링커에서 해당 심볼을 병합 할 기회가 없습니다. 일반적으로 이러한 기호는 템플릿 인스턴스의 정적 멤버 또는 클래스 impedimenta이며 다른 DLL의 코드간에 인스턴스를 전달할 때 문제를 발생시킵니다.
• 컴파일 중에 이미 동적 라이브러리에서 심볼을 가져올 지 여부를 하드 코딩합니다. 따라서 일부 라이브러리와 정적으로 링크 된 코드는 동일한 라이브러리와 동적으로 링크 된 코드와 호환되지 않습니다.

ELF 형식 내보내기를 사용하는 Unix는 첫 번째 문제를 피하기 위해 내 보낸 모든 기호를 내재적으로 가져오고 두 번째를 피하기 위해 정적 링크 시간까지 정적 및 동적으로 해결 된 기호를 구분하지 않습니다.

다른 문제는 컴파일러 플래그입니다. 이 문제는 여러 컴파일 단위로 구성된 모든 프로그램에 존재하며 동적 라이브러리가 필요하지 않습니다. 그러나 Windows에서는 훨씬 더 나쁩니다. 유닉스에서는 정적으로 또는 동적으로 링크하는지 여부는 중요하지 않으며, 아무도 표준 런타임을 정적으로 링크하지 않습니다 (Linux에서는 불법 일 수도 있음). 특별 디버그 런타임이 없으므로 하나의 빌드로 충분합니다. 그러나 Microsoft가 정적 및 동적 연결, 디버그 및 릴리스 런타임 및 기타 옵션을 구현 한 방식은 필요한 라이브러리 변형의 조합 폭발을 일으켰습니다. C ++ 언어 문제가 아닌 플랫폼 문제입니다.

아니.

헤더 시스템을 대체하기 위해 많은 작업이 진행 중입니다.이 기능은 모듈이라고하며 이것에 영향을 줄 수는 있지만 큰 것은 아닙니다.