진화하는 C++ std :: namespace를 처리하는 방법? 예 : std :: tr1 :: shared_ptr 대 std :: shared_ptr 대 boost :: shared_ptr 대 boost :: tr1 :: shared_ptr

Question

현재 작업하고있는 코드는 일부 오래된 시스템에서 컴파일해야하는 경우가 있습니다. 예전의 IBM BlueGene/L에서 심즈를 실행합니다. 누가 지원 계약을 맺으면 꽤 오래된 C++ 컴파일러가 될 것입니다. 코드 자체는 shared_ptrs를 사용하며 원래 std :: tr1 :: shared_ptr을 사용하도록 작성되었습니다. 이전 BlueGene 시스템에서 컴파일 할 때 tr1 :: 구현이 없으므로 boost :: shared_ptr로 전환했습니다. 거기에 boost :: tr1 :: shared_ptr도있다. 코드가 연구 그룹 외부에서 더 널리 사용되고 있으므로 이식성이 더욱 중요 해지고 있습니다.

큰 코드 코드베이스에서 이러한 종류의 표준 라이브러리 문제를 처리하는 가장 좋은 방법은 무엇입니까? 나는 새로운 C++ 11 표준에서 shared_ptr이 더 이상 tr1 네임 스페이스에 없기 때문에 다른 잠재력을 추가한다고 가정하고있다 : std :: shared_ptr, 그러나 이것은 널리 퍼진 지원이 될 것으로 생각된다. 가능한 한 최신 표준을 사용하고 싶지만 이식성을 유지해야합니다. 나는 부스트를 고수해야 할까? 귀하의 질문에

boost::tr1에

Answer 1

부분 대답은 tr1이없는 표준 라이브러리 구현을 정확히 발명된다. here에서 문서를 인용 :

TR1 라이브러리는 표준 라이브러리 확장에 C++ 기술 보고서 ​​ 의 구현을 제공합니다. 이 라이브러리는 자체적으로 TR1 구성 요소를 구현하지 않으며 표준 라이브러리의 TR1 구현 (있는 경우)을 포함하는 씬 래퍼입니다. 그렇지 않으면 에 부스트 라이브러리에 해당하는 내용이 포함되어 네임 스페이스 std : : tr1

Answer 2

왜 특별한 컴파일 시간을 확인하지 않습니까? 종류 :

부스트 라이브러리를 조회 할 수 있으며 컴파일러/버전 감지 코드가 많습니다.

매크로에 대한 자세한 내용은 입니다. 매크로에 대한 자세한 내용은 this question을 참조하십시오.

Answer 3

shared_ptr이있는 네임 스페이스를 찾으려면 autoconf와 같은 것이 필요합니다. 이것이 autoconf가 생성 된 이유입니다 (플랫폼/컴파일러 변형 검색). std::tr1::shared_ptr, boost::tr1::shared_ptr 및 boost::shared_ptr에 대한

AC_LANG(C++) 

AC_MSG_CHECKING([for std::shared_ptr]) 
AC_COMPILE_IFELSE([AC_LANG_PROGRAM(
    [[#include <memory>]] 
    [[std::shared_ptr<int> have_shared_ptr;]]) 
], [ 
    AC_MSG_RESULT([yes]) 
    AC_DEFINE_UNQUOTED([HAVE_STD_SHARED_PTR], 1, [Define to 1 if you have the `std::shared_ptr' class.]) 
], [ 
    AC_MSG_RESULT([no]) 
    AC_DEFINE_UNQUOTED([HAVE_STD_SHARED_PTR], 0, [Define to 1 if you have the `std::shared_ptr' class.]) 
]) 

반복 : 당신은이 작업을 수행 할 수 있습니다.

그런 다음 인 shared_ptr.hpp 파일을 만들 수 있습니다 뭔가 같은 :

이미 어디`표준 : shared_ptr`이 컴파일러는있다

ptr::shared_ptr<int> pointer(new int(5));