C ++ライブラリとフレームワークがスマートポインターを使用しないのはなぜですか？

私はいくつかの記事を読んで、生のポインタはほとんど使用してはならないことを述べました。代わりに、スコープ付きポインターでも共有ポインターでも、常にスマートポインター内にラップする必要があります。

しかし、Qtのようなフレームワーク、wxWidgets、Boostのようなライブラリーは、スマートポインターをまったく使用していないかのように、返ったり期待したりしないことに気づきました。代わりに、生のポインタを返すか期待します。その理由はありますか？パブリックAPIを作成するとき、スマートポインターに近づかないでください。なぜですか。

多くの主要なプロジェクトがスマートポインターを回避しているように思われるのに、なぜスマートポインターが推奨されるのか疑問に思っています。

多くのライブラリが標準のスマートポインタが登場する前に作成されたという事実は別として、最大の理由はおそらく標準のC ++アプリケーションバイナリインターフェース（ABI）の欠如です。

ヘッダーのみのライブラリを作成している場合は、スマートポインタと標準のコンテナをコンテンツに渡すことができます。それらのソースはコンパイル時にライブラリで利用できるため、実装ではなく、インターフェイスの安定性のみに依存します。

ただし、標準のABI がないため、通常、これらのオブジェクトをモジュールの境界を越えて安全に渡すことはできません。GCC shared_ptrはおそらくMSVC shared_ptrとは異なります。MSVC もIntelとは異なる場合がありますshared_ptr。同じコンパイラであっても、これらのクラスがバージョン間でバイナリ互換であるとは限りません。

要するに、ライブラリのビルド済みバージョンを配布する場合は、依存する標準のABIが必要です。Cにはありませんが、コンパイラベンダーは、特定のプラットフォームのCライブラリ間の相互運用性に優れており、事実上の標準があります。

この状況はC ++にはあまり良くありません。個々のコンパイラーは、独自のバイナリー間の相互運用を処理できるため、サポートされているすべてのコンパイラー（多くの場合、GCCおよびMSVC）のバージョンを配布するオプションがあります。しかし、これに照らして、ほとんどのライブラリはCインターフェイスをエクスポートするだけです。つまり、生のポインタを意味します。

ただし、非ライブラリコードでは、通常、rawよりスマートポインタを優先する必要があります。

多くの理由が考えられます。それらのいくつかをリストするには：

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;

スマートポインターとローポインターが異なると言う人にとっては、私はそれに同意します。上記のコードは単にと交換可能なコードを記述できるアイデアであり#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以前）には2つの問題があります。

• 非標準なので、各ライブラリは独自に再発明する傾向があります（NIHシンドロームと依存関係の問題）
• 潜在的なコスト

デフォルトそれはコストフリーであるという点で、スマートポインタは、ありますunique_ptr。残念ながら、最近登場したC ++ 11 moveセマンティクスが必要です。他のすべてのスマートポインターには、コストがかかる（shared_ptr、intrusive_ptr）、またはセマンティクスが理想的ではない（auto_ptr）。

C ++ 11 std::unique_ptrが近づいてきて、を持ってくると、ついにそれが終わったと思うように誘惑されます...私はそれほど楽観的ではありません。

ほとんどのC ++ 11を実装している主要なコンパイラはごくわずかで、最近のバージョンでのみ実装されています。QTやBoostなどの主要なライブラリは、しばらくの間C ++ 03との互換性を維持することをいとわないため、新しい光沢のあるスマートポインタを広く採用することはできません。

スマートポインターに近づかないでください。オブジェクトを渡す必要があるアプリケーションで特に役立ちます。

ライブラリは、単に値を返すか、オブジェクトにデータを入力する傾向があります。通常、多くの場所で使用する必要のあるオブジェクトがないため、スマートポインターを使用する必要はありません（少なくとも、インターフェイスではなく、内部で使用することができます）。

私が取り組んでいるライブラリを例にとると、開発の数か月後には、いくつかのクラス（すべてのクラスの3〜5％）でのみポインターとスマートポインターを使用していることに気付きました。

ほとんどの場所で参照による変数の受け渡しで十分でした。ヌルになる可能性のあるオブジェクトがある場合は常にスマートポインターを使用し、使用したライブラリーが強制する場合は生のポインターを使用しました。

編集（評判のためコメントできません）：参照による変数の受け渡しは非常に柔軟です。オブジェクトを読み取り専用にしたい場合は、const参照を使用できます（オブジェクトを書き込むために、いくつかの厄介なキャストを実行できます） ）しかし、最大限の保護が得られます（スマートポインターの場合も同じです）。しかし、オブジェクトを返すだけの方がはるかに良いことに同意します。

QtはJavaになるために、標準ライブラリの多くの部分を無意味に再発明しました。今は実際に独自のスマートポインターを持っていると思いますが、一般に、それはデザインの頂点ではありません。wxWidgetsは、私の知る限り、使用可能なスマートポインターが作成されるずっと前に設計されました。

Boostについては、適切な場所でスマートポインターを使用することを期待しています。もっと具体的にする必要があるかもしれません。

さらに、所有権を強制するためのスマートポインタが存在することを忘れないでください。APIに所有権セマンティクスがない場合、なぜスマートポインターを使用するのですか？

良い質問。私はあなたが参照する特定の記事を知りませんが、私は時々同じようなものを読みました。私の疑いは、そのような記事の作者はC ++スタイルのプログラミングに対する偏見を抱く傾向があるということです。ライターが必要な場合にのみC ++でプログラムを作成し、Javaなどにできるだけ早く戻る場合、C ++の考え方は共有されません。

同じライターの一部またはほとんどがガベージコレクションのメモリマネージャーを好むのではないかと疑う人もいます。私はそうではありませんが、私は彼らとは違った考え方をしています。

スマートポインターは優れていますが、参照カウントを維持する必要があります。参照カウントの維持には、実行時にコストがかかります（多くの場合、適度なコストですが、それでもコストがかかります）。特にポインタがデストラクタによって管理されている場合は、ベアポインタを使用してこれらのコストを節約しても問題はありません。

C ++の優れた点の1つは、組み込みシステムプログラミングのサポートです。ベアポインターの使用はその一部です。

更新： コメント作成者は、C ++の新しいunique_ptr（TR1以降で利用可能）は参照をカウントしないことを正しく観察しています。また、コメンターは「スマートポインター」の定義が私が思っているものとは異なります。彼はその定義について正しいかもしれません。

更なる更新： 以下のコメントスレッドは明快です。それはすべて読むことをお勧めします。

他のタイプのスマートポインターもあります。ネットワークレプリケーション（アクセスされたかどうかを検出してサーバーに変更を送信するなど）に特化したスマートポインターが必要な場合があり、変更の履歴を保持し、アクセスされたことをマークして、いつ調査できるかを示します。データをディスクなどに保存します。ポインターでそれを行うのが最善の解決策かどうかはわかりませんが、ライブラリで組み込みのスマートポインター型を使用すると、ユーザーがそれらにロックされて柔軟性が失われる可能性があります。

人々は、スマートポインターを超えて、あらゆる種類の異なるメモリ管理要件とソリューションを持つことができます。私は自分でメモリを管理したいかもしれません。実行時にではなく、事前に割り当てられるように、メモリプール内の物にスペースを割り当てることができます（ゲームに役立ちます）。私はガベージコレクションされたC ++の実装を使用している可能性があります（C ++ 11はまだ存在しませんが、これを可能にします）。または、私はそれらに悩まされることを心配するほど高度なことをしていないだけかもしれません。初期化されていないオブジェクトなどを忘れないことを知っているでしょう。多分私は、ポインタ松葉杖なしでメモリを管理する私の能力に自信があるだけです。

Cとの統合も別の問題です。

もう1つの問題は、スマートポインターがSTLの一部であることです。C ++は、STLがなくても使用できるように設計されています。

それはあなたがどのドメインで働いているかにも依存します。私は生活のためのゲームエンジンを書きます。私たちは疫病のようなブーストを避けます。ゲームではブーストのオーバーヘッドは許容できません。コアエンジンでは、独自のバージョンのstlを作成しました（ea stlとほぼ同じ）。

フォームアプリケーションを作成する場合は、スマートポインターの使用を検討します。しかし、メモリ管理が第二の性質になると、メモリをきめ細かく制御できなくなると、静かに迷惑になります。