c++ - C++ メモリ管理

Question

私は大学で、常に未使用のオブジェクトを解放する必要があることを学びましたが、実際に解放する方法は必要ありません。たとえば、コードを正しく構造化するなどです。C++ でポインターを処理する方法に関する一般的な規則はありますか?

現在、ブーストの使用は許可されていません。私が使用しているフレームワークではジェネリックの使用が禁止されているため、純粋な C++ に固執する必要があります。

score 14 · Accepted Answer

私は組み込みの Symbian OS を使用してきました。この OS は、完全に開発者の慣例に基づいて、このための優れたシステムを備えていました。

ポインタを所有するオブジェクトは 1 つだけです。デフォルトでは、これは作成者です。
所有権は譲渡できます。所有権の受け渡しを示すために、オブジェクトはメソッドシグネチャでポインタとして渡されます (例: void Foo(Bar *zonk);)。
所有者は、いつオブジェクトを削除するかを決定します。
使用するためだけにオブジェクトをメソッドに渡すには、オブジェクトをメソッドシグネチャで参照として渡します (例: void Foo(Bat &zonk);)。
非所有者クラスは、所有者が使用中にオブジェクトを破棄しないことが確実な場合にのみ、与えられたオブジェクトへの参照 (ポインターではありません) を格納できます。

基本的に、クラスが単純に何かを使用する場合は、参照を使用します。クラスが何かを所有している場合、ポインターを使用します。

これは美しく機能し、使用するのが楽しみでした。メモリの問題は非常にまれでした。

score 5 · Accepted Answer

ルール:

可能な限り、スマートポインターを使用してください。ブーストにはいくつかの良いものがあります。
スマートポインターを使用できない場合は、ポインターを削除した後、ポインターを無効にします。
ルール 1 を使用できない場所では絶対に作業しないでください。

誰かがルール 1 を許可しない場合、他の人のコードを入手して変数名を変更し、著作権表示を削除しても、誰も気付かないことを覚えておいてください。学校のプロジェクトでない限り、非常に洗練されたツールを使用して、実際にそのような悪ふざけをチェックします。この質問も参照してください。

score 3 · Accepted Answer

ここに別のルールを追加します。

自動オブジェクトが問題なく動作する場合は、オブジェクトを新規作成/削除しないでください。

C++ を初めて使用するプログラマー、または Java のような言語からやって来たプログラマーは、コンテキストに関係なく、オブジェクトを作成したいときはいつでも new について学習し、それを執拗に使用しているようです。これは、オブジェクトが関数内でローカルに作成され、何か有用なことを純粋に行う場合に特に有害です。このように new を使用すると、パフォーマンスが低下する可能性があり、対応する削除が忘れられたときにばかげたメモリリークが発生しやすくなります。はい、スマートポインターは後者に役立ちますが、パフォーマンスの問題は解決しません (new/delete または同等のものが舞台裏で使用されていると仮定します)。興味深いことに (おそらく)、Visual C++ を使用する場合、delete は new よりもコストがかかる傾向があることがわかりました。

この混乱の一部は、それらが呼び出す関数がポインター、またはスマートポインターを引数として取る可能性があるという事実からも生じます (参照の方がおそらくより適切/明確である場合)。これにより、関数にポインターを渡すことができるようにするには、ポインターを「作成」する必要があると考えるようになります (多くの人は、これが new の機能だと考えているようです)。明らかに、これには API の記述方法に関するいくつかの規則が必要であり、呼び出し規約を可能な限り明確にする必要があります。これは、関数プロトタイプで提供される明確なコメントで強化されます。

score 2 · Accepted Answer

一般的なケース (リソースが必ずしもメモリではないリソース管理) では、RAII パターンに精通している必要があります。これは、C++ 開発者にとって最も重要な情報の 1 つです。

score 2 · Accepted Answer

一般に、必要な場合を除き、ヒープからの割り当ては避けてください。必要に応じて、有効期間が長く、コードのさまざまな部分で共有する必要があるオブジェクトに対して参照カウントを使用します。

オブジェクトを動的に割り当てる必要がある場合もありますが、それらは特定の期間内でのみ使用されます。たとえば、以前のプロジェクトでは、データベーススキーマの複雑なメモリ内表現を作成する必要がありました。基本的には、オブジェクトの複雑な循環グラフです。ただし、グラフはデータベース接続中にのみ必要であり、その後はすべてのノードを 1 回で解放できました。この種のシナリオで使用するのに適したパターンは、私が「ローカル GC イディオム」と呼んでいるものです。それが「正式な」名前であるかどうかはわかりません。これは、私自身のコードと Cocoa でしか見たことがないためです ( Apple の Cocoa リファレンスのNSAutoreleasePoolを参照してください)。

簡単に言えば、new を使用して割り当てた一時オブジェクトへのポインターを保持する「コレクター」オブジェクトを作成します。これは通常、プログラム内の何らかのスコープに結び付けられます。静的スコープ (例: RAII イディオムを実装するスタック割り当てオブジェクトとして) または動的スコープ (例: データベース接続の有効期間に結び付けられる) のいずれかです。私の以前のプロジェクト）。「コレクター」オブジェクトが解放されると、そのデストラクタはそれが指すすべてのオブジェクトを解放します。

また、DrPizza のように、テンプレートを使用しないという制限は厳しすぎると思います。しかし、Solaris、AIX、および HP-UX の古いバージョンで多くの開発を行ってきたので (つい最近 - そうです、これらのプラットフォームはまだフォーチュン 50 に含まれています)、移植性を本当に気にかけているのであれば、テンプレートの使用は最小限にする必要があります。ただし、コンテナーとスマートポインターにそれらを使用することは問題ないはずです (私にとってはうまくいきました)。テンプレートがなければ、私が説明した手法を実装するのはより困難です。「コレクター」によって管理されるすべてのオブジェクトは、共通の基本クラスから派生する必要があります。

score 1 · Accepted Answer

G'day、

ScottMeyersによる「EffectiveC++」の関連セクションを読むことをお勧めします。読みやすく、彼は不注意をトラップするためのいくつかの興味深い落とし穴をカバーしています。

テンプレートがないことにも興味があります。したがって、STLやブーストはありません。わお。

ところで、人々に慣習に同意してもらうことは素晴らしい考えです。誰もがOODの慣習に同意するようになっています。ところで、Effective C ++の最新版には、初版にあったOOD規則に関する優れた章がありません。これは残念です。たとえば、パブリック仮想継承などの規則は常に「isa」関係をモデル化します。

ロブ

score 0 · Accepted Answer

手動でメモリの管理を使用する必要がある場合は、同じスコープ/関数/クラス/モジュールで delete を呼び出すようにしてください。
関数の呼び出し元に、それによって満たされたメモリを割り当てさせ、新しいポインターを返さないでください。
new を呼び出したのと同じ exe/dll で常に delete を呼び出します。そうしないと、ヒープの破損 (異なる互換性のないランタイムライブラリ) の問題が発生する可能性があるためです。

score 0 · Accepted Answer

(ref()/unref() メソッドとカウンターを使用して) 機能のようなスマートポインターを実装するいくつかの基本クラスからすべてを派生させることができます。

@Timbo によって強調表示されたすべてのポイントは、その基本クラスを設計するときに重要です。

c++ - C++ メモリ管理

8 に答える 8

Related

Reference