컴파일 된 C ++ 11 라이브러리 (lib, dll 등)를 이전 C ++ 컴파일러에서 연결할 수 있습니까?

구형 C ++ 컴파일러 (예 : VS2008 및 gcc3.4)가 C ++ 11로 작성된 외부 라이브러리와 연결할 수 있습니까?

내 생각에 C ++ 11 .lib 파일은이 단계에서 바이트 코드 일 뿐이며 어떻게 든 해석 가능하고 호출 가능한 한 이전 컴파일러가 생성 된 방식을 귀찮게해서는 안됩니다.

API가 여전히 C ++ 03 사용자를 지원해야하는 작은 라이브러리를 개발 중입니다. 그래서 기대되는 것처럼 유용한 기능을 사용하여 라이브러리를 구현해도 괜찮은지 궁금합니다 std::unique_ptr. 또는 그냥 고집해야 boost::합니까?

라이브러리가 구현시 C ++ 11 만 사용하고 C ++ 11 기능 또는 유형을 공개적으로 노출시키지 않는 경우, 특히 정적 링크를 사용하는 경우 가능하며 표준입니다.

라이브러리가 C- 레벨 인터페이스를 노출하지만 (다양한 클라이언트가 사용할 수 있음) C ++로 내부적으로 구현되는 일반적인 경우를 고려하십시오. 이러한 라이브러리에 연결하는 클라이언트는 공용 바이너리 API (내 보낸 함수)에 대해서만 걱정하면되며, 호환성을 극대화하기 위해 레거시 C / C ++로 제한됩니다. Java 프로그램은 내부적으로 C ++로 구현 된 C 레벨 API에 링크 할 수 있습니다. 그렇다고 Java가 "C ++"을 지원해야한다는 의미는 아닙니다. 마찬가지로 구식 C / C ++ 클라이언트는 내부적으로 C ++ 라이브러리 또는 다른 라이브러리의 일부 전위 버전을 사용하는 C 레벨 또는 C ++ 레벨 API에 연결할 수 있습니다. 라이브러리 인터페이스에 연결하는 데 필요한 것과 라이브러리 자체가 내부적으로 연결되는 (또는 정적으로 가져 오는) 두 가지가 있습니다.

라이브러리의 클라이언트를 구현의 종속성에 노출시키지 않습니다.

의존성 (C ++ 11 또는 다른 것)을 라이브러리에 정적으로 링크 할 수 있다면 깨끗하고 독립적입니다. 이 라이브러리는 바이트 코드 만있는 진정한 블랙 박스입니다. 그러나 라이브러리가 "암시 적 동적"링크 (명시 적 LoadLibrary / GetProcAddress 종류 및 * nix 및 OS X의 유사한 메소드와 혼동하지 않아야 함)를 통해 종속성에 링크 된 경우에도 이전 클라이언트는 여전히 해당 라이브러리의 링크에 연결할 수 있어야합니다. 공용 인터페이스는, 그들이 라이브러리에 링크 할 수 없습니다 경우에도 라이브러리에 따라 다릅니다 .

다른 사람들이 사용할 새 라이브러리를 작성하고 C + 11을 구현 언어로 사용하고 싶은 것 같습니다. 고려해야 할 여러 가지 문제가 있습니다.

• 새로운 버전의 C ++를 도입함으로써 라이브러리와 함께 새로운 C ++ 런타임 라이브러리를 배포 할 필요성을 소개 할 것입니다. 괜찮습니까?
• 당신은해야 하지 그렇지 않으면 호출 할 수 없습니다, 당신의 공용 인터페이스의 새로운 C + 11 종류를 사용합니다.
• 일반적으로 unique_ptr, even vector와 같은 복잡한 유형은 피해야합니다. 라이브러리를 소스 코드로 배포하지 않는 한 라이브러리의 객체 레이아웃은 클라이언트 코드의 레이아웃과 다를 수 있습니다. 객체 레이아웃 변형의 위험이없는 간단한 유형을 고수하십시오.