언제 Boost::shared_ptr 대신 std::auto_ptr을 사용하시겠습니까?

StackOverflow https://stackoverflow.com/questions/1227379

문제

우리는 거의 다음을 사용하여 이동했습니다. boost::shared_ptr 우리의 모든 코드에는 여전히 우리가 사용하는 몇 가지 고립된 경우가 있습니다. std::auto_ptr, 싱글톤 클래스 포함:

template < typename TYPE >
class SharedSingleton
{
public: 
    static TYPE& Instance()
    {
        if (_ptrInstance.get() == NULL)
            _ptrInstance.reset(new TYPE);
        return *_ptrInstance;
    }

protected: 
    SharedSingleton() {};

private:
    static std::auto_ptr < TYPE > _ptrInstance;
};

나는 이것이 만들어지지 않은 데에는 아주 타당한 이유가 있다고 들었습니다. shared_ptr, 하지만 평생 동안 왜 그런지 이해할 수 없습니까?나는 그것을 안다 auto_ptr 결국 다음 기준에서는 감가상각으로 표시될 것이므로 이 구현을 대체할 수 있는 내용/방법을 알고 있습니다..

또한, auto_ptr 대신에 shared_ptr? 그리고 앞으로 shared_ptr로 이동하는 데 문제가 있다고 보시나요?

편집하다:

  1. 그래서 "무사히 교체해도 될까요?"라는 질문에 auto_ptr ~와 함께 shared_ptr 위 코드에서 "예"라고 답했습니다. 하지만 성능에 약간의 타격이 있을 것입니다.
  2. 언제 auto_ptr 결국 감가 상각으로 표시되고 std::shared_ptr, 다양한 소유권 의미 체계를 준수하는지 확인하기 위해 코드를 철저하게 테스트해야 합니다.
도움이 되었습니까?

해결책

auto_ptr 그리고 shared_ptr 완전히 다른 문제를 해결합니다.하나는 다른 하나를 대체하지 않습니다.

auto_ptr 구현할 포인터 주위의 얇은 래퍼입니다. 라이 예외가 발생하더라도 리소스가 항상 해제되도록 하는 의미론입니다. auto_ptr 참조 계산 등을 전혀 수행하지 않으며 복사본을 생성할 때 여러 포인터가 동일한 객체를 가리키도록 만들지 않습니다.사실, 그것은 매우 다릅니다. auto_ptr 할당 연산자가 값을 수정하는 몇 안 되는 클래스 중 하나입니다. 원천 물체.이 뻔뻔한 플러그를 생각해 보세요. auto_ptr 위키피디아 페이지:

int *i = new int;
auto_ptr<int> x(i);
auto_ptr<int> y;

y = x;

cout << x.get() << endl; // Print NULL
cout << y.get() << endl; // Print non-NULL address i

실행 방법 참고

y = x;

y뿐만 아니라 x도 수정합니다.

그만큼 boost::shared_ptr 템플릿을 사용하면 동일한 객체에 대한 여러 포인터를 쉽게 처리할 수 있으며 객체에 대한 마지막 참조가 범위를 벗어난 후에만 객체가 삭제됩니다.이 기능은 구현을 시도하는 시나리오에서는 유용하지 않습니다. 하나씩 일어나는 것.귀하의 시나리오에는 클래스의 유일한 개체에 대한 참조가 1개 있는 경우 항상 0개의 참조가 있습니다.

본질적으로, auto_ptr 사물과 shared_ptr 객체는 완전히 다른 의미를 갖습니다(이것이 컨테이너에서 전자를 사용할 수 없는 이유이지만 후자를 사용하는 것은 괜찮습니다). 코드를 포팅하는 동안 발생한 회귀를 포착할 수 있는 좋은 테스트가 있기를 바랍니다.:-}

다른 팁

다른 사람들은이 코드가 왜 AN을 사용하는지 대답했습니다 auto_ptr 대신 a shared_ptr. 다른 질문을 해결하려면 :

이 구현을 어떻게 대체 할 수 있습니까?

어느 쪽이든 사용하십시오 boost::scoped_ptr 또는 unique_ptr (부스트와 새로운 C ++ 표준 모두에서 사용할 수 있습니다). 둘 다 scoped_ptr 그리고 unique_ptr 엄격한 소유권을 제공하고 (및 참조 계산 오버 헤드가 없음) 놀라운 삭제-송아지의 시맨틱을 피하십시오. auto_ptr.

또한, 당신이 사용하는 것을 고려하는 다른 이유가 있습니까? auto_ptr 대신 a shared_ptr? 그리고 어떤 문제가 발생하는지 보십니까? shared_ptr 미래에?

개인적으로 나는 사용하지 않을 것입니다 auto_ptr. Copy를 삭제하는 것은 너무 직관적이지 않습니다. 허브 셔터는 동의하는 것 같습니다. 전환 scoped_ptr, unique_ptr, 또는 shared_ptr 아무런 문제가 없어야합니다. 구체적으로, shared_ptr 참조 카운트 오버 헤드에 신경 쓰지 않으면 드롭 인 교체가되어야합니다. scoped_ptr 사용하지 않는 경우 드롭 인 교체입니다 auto_ptr의 전송 기능. 그렇다면 이체 소유권을 사용하는 경우 unique_ptr 대신 명시 적으로 전화해야한다는 점을 제외하고는 거의 드롭 인 교체품입니다. move 소유권을 양도합니다. 보다 여기 예를 들어.

Auto_ptr은 내가 사용하는 유일한 종류의 스마트 포인터입니다. 나는 부스트를 사용하지 않기 때문에 그것을 사용하고, 일반적으로 비즈니스/애플리케이션 지향 클래스를 선호하기 때문에 삭제 시맨틱과 질서를 명시 적으로 정의하는 것이 아니라 개별 또는 스마트 포인터의 수집에 의존하기 때문입니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top