参照カウントのスマートポインターが人気があるのはなぜですか？

ご覧のとおり、スマートポインターは多くの実際のC ++プロジェクトで広く使用されています。

ある種のスマートポインターはRAIIと所有権の移行をサポートするために明らかに有益ですが、プログラマーが割り当てをそれほど考慮する必要がないように、「ガベージコレクション」の方法として共有ポインターをデフォルトで使用する傾向もあります。

Boehm GCのような適切なガベージコレクターを統合するよりも、共有ポインターの方が人気があるのはなぜですか？（または、実際のGCよりも人気があることにまったく同意しますか？）

参照カウントに対する従来のGCの2つの利点について知っています。

• 従来のGCアルゴリズムには、参照サイクルに関する問題はありません。
• 参照カウントは通常、適切なGC よりも遅くなります。

参照カウントスマートポインターを使用する理由は何ですか？

ガベージコレクションに対する参照カウントの利点：

1. 低オーバーヘッド。ガベージコレクターは非常に邪魔になり（たとえば、ガベージコレクションサイクルの処理中に予測不能な時間にプログラムがフリーズする）、非常にメモリ集約型です（たとえば、ガベージコレクションが最終的に開始される前にプロセスのメモリフットプリントが不必要に数メガバイトに増加する）

2. より予測可能な動作。参照カウントを使用すると、オブジェクトへの最後の参照がなくなるとすぐにオブジェクトが解放されることが保証されます。一方、ガベージコレクションを使用すると、システムがそれに到達したときにオブジェクトが「いつか」解放されます。RAMの場合、これは通常、デスクトップや負荷の軽いサーバーでは大きな問題ではありませんが、他のリソース（ファイルハンドルなど）の場合、潜在的な競合を避けるためにできるだけ早く閉じる必要があります。

3. よりシンプル。参照カウントは数分で説明でき、1〜2時間で実装できます。ガベージコレクター、特に適切なパフォーマンスを備えたガベージコレクターは非常に複雑であり、多くの人が理解しているわけではありません。

4. 標準。C ++には（shared_ptrを介した）参照カウントとSTLのフレンドが含まれています。つまり、ほとんどのC ++プログラマーはこれに精通しており、ほとんどのC ++コードが動作します。ただし、標準のC ++ガベージコレクターはありません。つまり、いずれかを選択し、ユースケースでうまく機能することを期待する必要があります。そうでない場合は、言語ではなく修正するのが問題です。

参照カウントのマイナス面については-サイクルを検出しないことは問題ですが、参照カウントを使用して過去10年間に個人的に遭遇したことはありません。ほとんどのデータ構造は自然に非循環的であり、循環参照（ツリーノードの親ポインターなど）が必要な状況に遭遇した場合は、weak_ptrまたはraw Cポインターを「逆方向」に使用できます。データ構造を設計するときに潜在的な問題を認識している限り、それは問題ではありません。

パフォーマンスに関しては、参照カウントのパフォーマンスに問題はありませんでした。ガベージコレクションのパフォーマンス、特にGCで発生する可能性のあるランダムフリーズに問題があり、唯一の解決策（「オブジェクトを割り当てない」）は「GCを使用しない」と言い換えることができます。 。

GCから優れたパフォーマンスを引き出すには、GCがメモリ内のオブジェクトを移動できる必要があります。メモリの場所と直接やり取りできるC ++のような言語では、これはほとんど不可能です。（Microsoft C ++ / CLRは、GC管理ポインターの新しい構文を導入し、事実上異なる言語であるためカウントされません。）

Boehm GCは気の利いたアイデアではありますが、実際には両方の世界で最悪です。適切なGCよりも遅いmalloc（）が必要なので、世代別GCの対応するパフォーマンスブーストなしで決定論的な割り当て/割り当て解除の動作を失います。さらに、必然的に保守的であるため、とにかくすべてのゴミを収集する必要はありません。

適切に調整された適切なGCは素晴らしいことです。しかし、C ++のような言語では、利益は最小限であり、多くの場合、コストは価値がありません。

しかし、C ++ 11の人気が高まるにつれて、ラムダとキャプチャセマンティクスがC ++コミュニティを最初のLispコミュニティにGCを発明させたのと同じ種類の割り当てとオブジェクトライフタイムの問題に導くかどうかは興味深いでしょう。場所。

StackOverflowの関連する質問に対する私の回答も参照してください。

ご覧のとおり、スマートポインターは多くの実際のC ++プロジェクトで広く使用されています。

確かに、客観的には、コードの大部分は、ガベージコレクターをトレースする最新の言語で記述されています。

ある種のスマートポインターはRAIIと所有権の移行をサポートするために明らかに有益ですが、プログラマーが割り当てについてそれほど考える必要がないように、「ガベージコレクション」の方法として共有ポインターをデフォルトで使用する傾向もあります。

サイクルについて心配する必要があるため、これは悪い考えです。

Boehm GCのような適切なガベージコレクターを統合するよりも、共有ポインターの方が人気があるのはなぜですか？（または、実際のGCよりも人気があることにまったく同意しますか？）

おお、すごい、あなたの考え方に多くの間違いがあります：

1. BoehmのGCは、いかなる意味でも「適切な」GCではありません。それは本当にひどいです。それは保守的であるため、リークして設計上非効率的です。参照：http : //flyingfrogblog.blogspot.co.uk/search/label/boehm

2. 共有ポインターは客観的には、GCほど人気が​​ありません。開発者の大多数が現在GC化された言語を使用しており、共有ポインターを必要としないためです。C ++と比較して、雇用市場でJavaとJavascriptを見てください。

3. GCが接線的な問題だと思うので、C ++への考慮を制限しているように見えます。そうではない（まともなGCを取得する唯一の方法は、最初から言語とVMを設計することです）ので、選択バイアスを導入しています。適切なガベージコレクションが本当に必要な人は、C ++に固執しません。

参照カウントスマートポインターを使用する理由は何ですか？

C ++に制限されていますが、自動メモリ管理が必要です。

MacOS XとiOS、およびObjective-CまたはSwiftを使用する開発者では、参照カウントは自動的に処理されるため人気があり、ガベージコレクションの使用はAppleがもうサポートしていないためかなり減少しています（使用しているアプリはガベージコレクションは次のMacOS Xバージョンで破損し、ガベージコレクションはiOSで実装されませんでした。ガベージコレクションが使用可能になったときに、ガベージコレクションを使用するソフトウェアがこれまでにたくさんあったことを、私は実際に真剣に疑っています。

ガベージコレクションを削除する理由：ガベージコレクタがアクセスできない領域にポインタが「エスケープ」できるCスタイルの環境では、確実に機能しませんでした。Appleは、参照カウントが高速であると強く信じ、信じています。（ここで相対的な速度について主張することができますが、Appleを納得させることはできませんでした）。そして、結局、誰もガベージコレクションを使用しませんでした。

MacOS XまたはiOS開発者が最初に学ぶことは、参照サイクルの処理方法です。したがって、実際の開発者にとっては問題ではありません。

C ++のガベージコレクションの最大の欠点は、正しく処理することが不可能であることです。

• C ++では、ポインターは独自のウォールコミュニティに存在せず、他のデータと混在しています。そのため、ポインターを、たまたま有効なポインターとして解釈できるビットパターンを持つ他のデータと区別することはできません。

  結果：C ++ガベージコレクターは、収集する必要があるオブジェクトをリークします。

• C ++では、ポインター演算を行ってポインターを導出できます。そのため、ブロックの先頭へのポインタが見つからない場合、そのブロックを参照できないという意味ではありません。

  結果：C ++ガベージコレクターはこれらの調整を考慮する必要があり、ブロックの末尾直後を含むブロック内の任意の場所を指すビットシーケンスを、ブロックを参照する有効なポインターとして扱います。

  注：C ++ガベージコレクターは、次のようなトリックでコードを処理できません。

  int* array = new int[7];
  array--;    //undefined behavior, but people may be tempted anyway...
  for(int i = 1; i <= 7; i++) array[i] = i;

  確かに、これは未定義の動作を呼び出します。ただし、既存のコードの中には、それよりも優れたものがあり、ガベージコレクターによる事前の割り当て解除をトリガーする場合があります。