boost :: shared_ptr 사용에서 std :: shared_ptr로 전환해야합니까?

boost :: shared_ptr 사용에서 std :: shared_ptr로 전환해야합니까?

---

.NET을 사용하여 GCC에서 C ++ 0x에 대한 지원을 활성화하고 싶습니다 -std=c++0x. GCC 4.5 (그리고 곧 4.6)에서 현재 지원되는 C ++ 11 기능이 반드시 필요 하지는 않지만 익숙해지기 시작하고 싶습니다. 예를 들어, 반복기를 사용하는 몇 군데에서 auto유형이 유용 할 것입니다.

그러나 다시 말하지만 현재 지원되는 기능은 필요 하지 않습니다 . 여기서의 목표는 새로운 표준의 기능을 프로그래밍 "어휘"에 통합하도록 권장하는 것입니다.

C ++ 11 지원에 대해 알고있는 바에 따르면 GCC에서 활성화 한 다음 두 가지가 혼합되지 않기 때문에 사용 boost::shared_ptr에서 std::shared_ptr독점으로 전환하여이를 수용하는 것이 좋은 생각 입니까?

추신 : 나는 다른 맛을 비교하는 이 좋은 질문 을 알고 shared_ptr있지만 표준이 완성되기 전에 사용할 더 높은 수준의 조언을 요청하고 있습니다. 또 다른 방법은 GCC와 같은 컴파일러가 "실험적 기능"을 지원한다고 말하면 컴파일 중에 StackOverflow에 대한 주요 시간 싱크 및 비밀 질문의 원인이 될 이상한 오류가 발생할 가능성이 있다는 의미입니까?

편집 : 나는 이 질문의 예에서 볼 수 있듯이std::shared_ptr GCC 4.5에서의 지원을 신뢰하지 않기 때문에 다시 전환하기로 결정했습니다 .

---

다음으로 전환해야하는 몇 가지 이유가 있습니다 std::shared_ptr.

• Boost에 대한 종속성을 제거합니다.
• 디버거. 컴파일러와 디버거에 따라 디버거는 "스마트"할 수 있으며 std::shared_ptr, 부스트 구현과는 달리 직접 가리키는 객체를 표시 할 수 있습니다 . 적어도 Visual Studio에서는 std::shared_ptr디버거의 일반 포인터처럼 보이지만 boost::shared_ptr많은 부스트 ​​내부 를 노출합니다.
• 링크 된 질문에 정의 된 기타 새로운 기능.
• 이동 시맨틱이 활성화 된 것으로 거의 보장되는 구현을 얻을 수 있으며, 이는 몇 가지 refcount 수정을 절약 할 수 있습니다. (이론적으로-나는 이것을 직접 테스트하지 않았습니다) 적어도 2014-07-22부터 boost::shared_ptr이동 의미론을 이해합니다.
• std::shared_ptr올바르게 사용 delete []하면서, 배열 유형에 boost::shared_ptr원인이 이러한 경우에 행동 (당신이 사용해야 정의되지 않은 shared_array또는 사용자 정의 Deleter가) (. 사실 내가 그렇군요보기 이 - 이것에 대한 전문화가 있습니다 unique_ptr만하지 shared_ptr.)

다음을하지 않는 한 가지 중요한 이유 :

• C ++ 11 컴파일러 및 표준 라이브러리 구현으로 제한됩니다.

마지막으로 실제로 선택할 필요가 없습니다. (특정 컴파일러 시리즈 (예 : MSVC 및 GCC)를 대상으로하는 std::tr1::shared_ptr경우 사용 가능할 때 사용 하도록 쉽게 확장 할 수 있습니다. 안타깝게도 TR1 지원을 감지하는 표준 방법이없는 것 같습니다.)

#if __cplusplus > 199711L
#include <memory>
namespace MyProject
{
    using std::shared_ptr;
}
#else
#include <boost/shared_ptr.hpp>
namespace MyProject
{
    using boost::shared_ptr;
}
#endif

---

부스트를 얼마나 사용하는지에 달려 있다고 생각합니다. 저는 개인적으로 매우 드물게 사용합니다 (사실 단일 프로젝트에서 난수 라이브러리). 최근에 -std=c++0x다른 프로젝트에 사용 하기 시작했으며 shared_ptr과 같은 새로운 std :: 라이브러리 기능을 사용합니다. 내 프로젝트에 최소한의 종속성이있는 것이 좋으므로 부스트보다는 컴파일러의 표준 라이브러리 구현에 의존하는 편이 더 낫습니다.

그러나 나는이 질문에 대한 한 가지 크기의 대답은 없다고 생각한다.

---

std::shared_ptr가능한 경우 부스트 대신 항상 사용 하는 것이 좋습니다. 이것은 기본적으로 사용하는 모든 새로운 인터페이스가 shared_ptr표준 공유 ptr 을 사용하기 때문 입니다.

---

컴파일러에서 허용하는 경우 std :: shared_ptr을 사용하는 습관을들이는 것은 나쁘지 않을 것입니다. 인터페이스가 boost의 shared_ptr과 동일하기 때문에 필요한 경우 언제든지 다시 전환 할 수 있습니다.

---

괜찮은 하나의 플랫폼에서 빌드하는 경우 (전환을 수행하십시오)
(참고 : 이전 버전과의 호환성을 확인하는 단위 테스트가 있습니까?)

여러 플랫폼에서 컴파일하는 경우 g ++ 4.5의 기능이 사용하는 모든 플랫폼에서 사용 가능한지 확인해야하기 때문에 조금 더 어색해집니다 (예 : MAC / Linux 용으로 빌드하는 경우 기본 Mac g ++ 컴파일러는 여전히 Linux의 기본 컴파일러 뒤에있는 버전).

---

로 전환해야하는 또 다른 이유 std::shared_ptr는 std::unique_ptr, 즉 생성자를 지원합니다 .

boost::shared_ptr 하지 않습니다.

---

구현 일관성 외에도 boost::shared_ptr현재는 다음과 비교하여 최소 두 가지 틈새 이점을 유지합니다 std::shared_ptr.

• 의 가용성 boost::make_shared_noinit. 이것은 배열과 함께 사용할 때 특히 유용하며, 초기화 비용과 별도 할당의 오버 헤드를 모두 피할 수 있습니다. (FWIW, 표준에 대한 추가 제안 이기도합니다 .)
• Boost.Python은 boost::shared_ptr유형이 삭제 된 사용자 지정 삭제 자에 대한의 지원을 특별히 사용 하지만 아직std::shared_ptr .

---

std :: shared_ptr이 boost :: shared_ptr보다 빠릅니다. 테스트를했고 코드를 검토하고 boost, Qt 및 std 공유 포인터를 비교하는 파이 차트 결과를 볼 수 있습니다.

https : //www.osletek.com ...

참고URL : https://stackoverflow.com/questions/6322245/should-i-switch-from-using-boostshared-ptr-to-stdshared-ptr