C ++ 라이브러리 및 프레임 워크가 스마트 포인터를 사용하지 않는 이유는 무엇입니까?

필자는 원시 포인터를 거의 사용해서는 안된다는 기사를 몇 개 읽었습니다. 대신 범위 또는 공유 포인터에 관계없이 항상 스마트 포인터 내부에 래핑되어야합니다.

그러나 Qt, wxWidgets 및 Boost와 같은 라이브러리와 같은 프레임 워크는 마치 전혀 사용하지 않는 것처럼 스마트 포인터를 반환하거나 기대하지 않습니다. 대신 원시 포인터를 반환하거나 기대합니다. 그 이유가 있습니까? 공개 API를 작성할 때 스마트 포인터를 멀리해야하나요? 그 이유는 무엇인가요?

많은 주요 프로젝트에서 스마트 포인터를 피하는 것처럼 보일 때 왜 스마트 포인터가 권장되는지 궁금합니다.

표준 스마트 포인터가 등장하기 전에 많은 라이브러리가 작성되었다는 사실을 제외하고 가장 큰 이유는 표준 C ++ ABI (Application Binary Interface)가 없기 때문일 것입니다.

헤더 전용 라이브러리를 작성하는 경우 스마트 포인터와 표준 컨테이너를 마음대로 전달할 수 있습니다. 그들의 소스는 컴파일 타임에 라이브러리에서 사용할 수 있으므로 구현이 아닌 인터페이스의 안정성에만 의존합니다.

그러나 표준 ABI가 없기 때문에 일반적으로 이러한 개체를 모듈 경계를 넘어 안전하게 전달할 수 없습니다 . GCC shared_ptr는 MSVC shared_ptr와 다를 수 있으며 Intel과 다를 수도 있습니다 shared_ptr. 동일한 컴파일러를 사용 하더라도 이러한 클래스는 버전간에 바이너리 호환이 보장되지 않습니다.

결론은 라이브러리 의 미리 빌드 된 버전 을 배포 하려면 의존 할 표준 ABI가 필요하다는 것입니다. C에는 없지만 컴파일러 공급 업체는 주어진 플랫폼에 대한 C 라이브러리 간의 상호 운용성에 대해 매우 우수합니다. 사실상 표준이 있습니다.

상황은 C ++만큼 좋지 않습니다. 개별 컴파일러는 자체 바이너리 간의 상호 운용을 처리 할 수 ​​있으므로 지원되는 모든 컴파일러 (종종 GCC 및 MSVC)에 대한 버전을 배포 할 수 있습니다. 그러나이를 고려하면 대부분의 라이브러리는 C 인터페이스 만 내 보냅니다. 즉, 원시 포인터를 의미합니다.

그러나 비 라이브러리 코드는 일반적으로 원시보다 스마트 포인터를 선호해야합니다.

여러 가지 이유가있을 수 있습니다. 몇 가지를 나열하려면 다음을 수행하십시오.

1. 스마트 포인터는 최근에 표준의 일부가되었습니다. 그때까지 그들은 다른 도서관의 일부였습니다
2. 주요 용도는 메모리 누수를 방지하는 것입니다. 많은 라이브러리에는 자체 메모리 관리 기능이 없습니다. 일반적으로 유틸리티와 API를 제공합니다.
3. 그것들은 실제로 포인터가 아니라 객체이기 때문에 래퍼로 ​​구현됩니다. 원시 포인터에 비해 추가 시간 / 공간 비용이 있습니다. 도서관 사용자는 이러한 오버 헤드를 원하지 않을 수 있습니다.

편집 : 스마트 포인터 사용은 완전히 개발자의 선택입니다. 다양한 요인에 따라 다릅니다.

1. 성능이 중요한 시스템에서는 오버 헤드를 생성하는 스마트 포인터를 사용하지 않을 수 있습니다.

2. 이전 버전과의 호환성이 필요한 프로젝트, C ++ 11 특정 기능이있는 스마트 포인터를 사용하고 싶지 않을 수 있습니다.

Edit2 아래 통과로 인해 24 시간 동안 여러 개의 반대표가 있습니다. 아래는 추가 제안 일 뿐이며 답변이 아닌데도 왜 답변이 비추천인지 이해하지 못합니다.
그러나 C ++는 항상 옵션을 열 수 있도록합니다. :) 예

template<typename T>
struct Pointer {
#ifdef <Cpp11>
  typedef std::unique_ptr<T> type;
#else
  typedef T* type;
#endif
};

그리고 코드에서 다음과 같이 사용하십시오.

Pointer<int>::type p;

스마트 포인터와 원시 포인터가 다르다고 말하는 사람들에게는 동의합니다. 위의 코드는 단지 a와 교환 할 수있는 코드를 작성할 수 있는 아이디어 일뿐입니다. #define이것은 강제 가 아닙니다 .

예를 들어 T*는 명시 적으로 삭제해야하지만 스마트 포인터는 삭제하지 않습니다. 우리는 Destroy()그것을 처리 할 템플릿 을 가질 수 있습니다 .

template<typename T>
void Destroy (T* p)
{
  delete p;
}
template<typename T>
void Destroy (std::unique_ptr<T> p)
{
  // do nothing
}

다음과 같이 사용하십시오.

Destroy(p);

같은 방식으로 원시 포인터의 경우 직접 복사 할 수 있고 스마트 포인터의 경우 특수 작업을 사용할 수 있습니다.

Pointer<X>::type p = new X;
Pointer<X>::type p2(Assign(p));

다음 Assign()과 같습니다.

template<typename T>
T* Assign (T *p)
{
  return p;
}
template<typename T>
... Assign (SmartPointer<T> &p)
{
  // use move sematics or whateve appropriate
}

스마트 포인터 (C ++ 11 이전)에는 두 가지 문제가 있습니다.

• 비표준, 따라서 각 라이브러리는 자체적으로 재창조하는 경향이 있습니다 (NIH 신드롬 및 종속성 문제).
• 잠재적 비용

기본 은 비용이없는 점에서 스마트 포인터는 것입니다 unique_ptr. 불행히도 최근에 등장한 C ++ 11 이동 의미론이 필요합니다. 다른 모든 스마트 포인터는 비용 ( shared_ptr, intrusive_ptr)이 있거나 이상적인 의미 ( auto_ptr) 보다 낮습니다 .

C ++ 11이 다가 오면를 가져 오면 std::unique_ptr마침내 끝났다고 생각하고 싶을 것입니다. 저는 그렇게 낙관적이지 않습니다.

소수의 주요 컴파일러 만이 대부분의 C ++ 11을 최신 버전에서만 구현합니다. QT 및 Boost와 같은 주요 라이브러리가 잠시 동안 C ++ 03과의 호환성을 유지할 것으로 예상 할 수 있으며, 이는 새롭고 반짝이는 스마트 포인터의 광범위한 채택을 다소 배제합니다.

스마트 포인터에서 멀리 떨어져서는 안되며, 특히 개체를 전달해야하는 응용 프로그램에서 사용됩니다.

라이브러리는 값을 반환하거나 객체를 채우는 경향이 있습니다. 일반적으로 많은 장소에서 사용해야하는 개체가 없으므로 스마트 포인터를 사용할 필요가 없습니다 (적어도 인터페이스가 아니라 내부적으로 사용할 수 있음).

몇 달 동안 개발 한 후 몇 개의 클래스 (모든 클래스의 3 ~ 5 %)에서만 포인터와 스마트 포인터 만 사용했음을 깨달은 라이브러리를 예로 들어 보겠습니다.

참조 에 의한 변수 전달 은 대부분의 장소에서 충분했습니다. 우리는 null이 될 수있는 객체가있을 때마다 스마트 포인터를 사용했고, 우리가 사용한 라이브러리가 강제 할 때 원시 포인터를 사용했습니다.

편집 (내 평판 때문에 주석을 달 수 없음) : 참조로 변수를 전달하는 것은 매우 유연합니다. 객체가 읽기 전용이되도록하려면 const 참조를 사용할 수 있습니다 (객체를 작성할 수 있도록 몇 가지 불쾌한 캐스트를 수행 할 수 있습니다. ) 그러나 가능한 최대의 보호를 얻을 수 있습니다 (스마트 포인터와 동일). 그러나 나는 객체를 반환하는 것이 훨씬 더 좋다는 데 동의합니다.

Qt는 Java가되기 위해 Standard 라이브러리의 많은 부분을 무의미하게 재발 명했습니다. 지금은 실제로 자체 스마트 포인터가 있다고 생각하지만 일반적으로 디자인의 정점은 아닙니다. 내가 아는 한 wxWidgets는 사용 가능한 스마트 포인터가 작성되기 훨씬 전에 설계되었습니다.

Boost의 경우 적절한 곳에서 스마트 포인터를 사용할 것으로 기대합니다. 좀 더 구체적이어야 할 수도 있습니다.

또한 소유권을 강화하기 위해 스마트 포인터가 존재한다는 사실을 잊지 마십시오. API에 소유권 의미가없는 경우 스마트 포인터를 사용하는 이유는 무엇입니까?

좋은 질문. 나는 당신이 언급하는 특정 기사를 모르지만 비슷한 것을 때때로 읽었습니다. 내 의심은 그러한 기사의 작성자가 C ++ 스타일 프로그래밍에 대한 편견을 품는 경향이 있다는 것입니다. 작가가 꼭 필요한 경우에만 C ++로 프로그래밍 한 다음 가능한 한 빨리 Java로 돌아 가면 C ++ 사고 방식을 공유하지 않습니다.

동일한 작성자 중 일부 또는 대부분이 가비지 수집 메모리 관리자를 선호한다고 의심하는 사람이 있습니다. 나는 그렇지 않지만 그들과는 다르게 생각합니다.

스마트 포인터는 훌륭하지만 참조 횟수를 유지해야합니다. 참조 횟수를 유지하면 비용 (종종 적당한 비용)이 발생하지만 그럼에도 불구하고 런타임에 비용이 발생합니다. 특히 포인터가 소멸자에 의해 관리되는 경우 베어 포인터를 사용하여 이러한 비용을 절약하는 데 아무런 문제가 없습니다.

C ++의 뛰어난 점 중 하나는 임베디드 시스템 프로그래밍에 대한 지원입니다. 베어 포인터를 사용하는 것도 그 일부입니다.

업데이트 : 한 댓글 작성자가 C ++의 새로운 기능 unique_ptr(TR1 이후 사용 가능)이 참조를 계산하지 않는다는 것을 올바르게 관찰했습니다 . 댓글 작성자는 내가 생각하는 것과는 다른 "스마트 포인터"정의를 가지고 있습니다. 그는 정의에 대해 옳을 수 있습니다.

추가 업데이트 : 아래 댓글 스레드가 밝게 표시됩니다. 모두 읽기를 권장합니다.

다른 유형의 스마트 포인터도 있습니다. 네트워크 복제 (액세스 여부를 감지하고 서버에 대한 수정 사항을 전송하는 것), 변경 내역을 유지하고, 액세스 사실을 표시하여 언제 조사 할 수 있는지에 대한 특수한 스마트 포인터를 원할 수 있습니다. 디스크 등에 데이터를 저장합니다. 포인터에서 그렇게하는 것이 최선의 해결책인지 확실하지 않지만 라이브러리에 내장 된 스마트 포인터 유형을 사용하면 사람들이 그 안에 갇혀 유연성을 잃을 수 있습니다.

사람들은 스마트 포인터 이상의 다양한 메모리 관리 요구 사항과 솔루션을 가질 수 있습니다. 메모리를 직접 관리하고 싶을 수도 있고, 메모리 풀에 공간을 할당하여 런타임이 아닌 미리 할당 할 수도 있습니다 (게임에 유용함). C ++의 가비지 수집 구현을 사용하고있을 수 있습니다 (아직 존재하지 않지만 C ++ 11에서는이를 가능하게 함). 아니면 내가 그들에게 신경을 쓸까 봐 걱정할만큼 고급스러운 일을하지 않을 수도 있고, 초기화되지 않은 객체 등을 잊지 않을 것임을 알 수 있습니다. 포인터 목발없이 기억을 관리하는 능력에 자신이있을 수 있습니다.

C와의 통합도 또 다른 문제입니다.

또 다른 문제는 스마트 포인터가 STL의 일부라는 것입니다. C ++는 STL없이 사용할 수 있도록 설계되었습니다.

그것은 또한 당신이 일하는 도메인에 달려 있습니다. 저는 생계를 위해 게임 엔진을 작성합니다. 우리는 전염병과 같은 부스트를 피합니다. 게임에서 부스트의 오버 헤드는 용납되지 않습니다. 핵심 엔진에서 우리는 우리 자신의 stl 버전 (ea stl과 매우 유사)을 작성했습니다.

양식 애플리케이션을 작성하려면 스마트 포인터 사용을 고려할 수 있습니다. 그러나 일단 메모리 관리가 제 2의 성질이면 메모리를 세밀하게 제어하지 못하는 것은 조용해집니다.