C ++では、メモリ管理にプログラマーが費やす時間

ガベージコレクションされた言語に慣れている人は、C ++のメモリ管理が怖いことがよくあります。そこのツールは次のように、あるauto_ptrとshared_ptrそれはあなたのためのメモリ管理タスクの多くを処理します。多くのC ++ライブラリはこれらのツールより前のものであり、メモリ管理タスクを処理する独自の方法があります。

メモリ管理タスクにどれくらいの時間を費やしていますか？

使用するライブラリのセットに大きく依存しているのではないかと思われるので、どのライブラリに答えが当てはまるか、それらが良くなるか悪くなるかを言ってください。

最新のC ++では、必要になるまで、つまり主に最適化のために、またはコンテキストによって強制される場合に（大規模な制約のあるハードウェアを考えて）手動でメモリを整理するまで、メモリ管理について心配する必要はありません。生のメモリを操作せずにゲーム全体を記述しましたが、他の言語と同様に、仕事に適したツールであるコンテナの使用のみを心配しています。

したがって、プロジェクトに依存しますが、ほとんどの場合、メモリ管理ではなく、オブジェクトのライフタイムのみを処理する必要があります。これは、スマートポインターを使用して解決されます。スマートポインターは、RAIIに起因する慣用的なC ++ツールの1つです。

RAIIを理解すれば、メモリ管理は問題になりません。

次に、生メモリにアクセスする必要がある場合は、「どこでも」ではなく、プールオブジェクトの実装のように、非常に具体的でローカライズされた識別可能なコードでアクセスします。

この種のコード以外では、メモリを操作する必要はなく、オブジェクトの寿命だけが必要です。

「難しい」部分はRAIIを理解することです。

メモリー管理は子供を怖がらせるために使用されますが、プログラマーが面倒を見る必要があるのはリソースの一種です。ファイルハンドル、ネットワーク接続、OSから取得するその他のリソースについて考えてください。

ガベージコレクションをサポートする言語は通常、これらのリソースの存在を無視するだけでなく、デストラクタを提供しないことでこれらを適切に処理することを難しくします。

要するに、C ++開発者の多くの時間をメモリ管理の心配に費やすことはお勧めしません。以下のようklaimの答えあなたはRAIIのハンドルを得れば、残りはちょうど反射で、示しています。

ほとんどありません。COMのような古いテクノロジーでさえ、非常に短時間でそれらを変換する標準ポインター用のカスタム削除機能を作成できます。たとえばstd::unique_ptr、カスタム削除機能の5行でCOM参照を一意に保持するように変換できます。独自のリソースハンドラを手動で記述する必要がある場合でも、SRPやコピーアンドスワップなどの知識が普及しているため、リソース管理クラスを比較的簡単に記述して、いつまでも使い続けることができます。

現実には、共有、一意、および非所有権はすべてC ++ 11コンパイラに同梱されており、古いコードでも動作するように小さなアダプタを記述する必要があります。

私がC ++プログラマーだった頃（ずっと前）、バグを再現するのが難しいのを修正しようとすると、メモリ管理のバグについて長い間心配していました。

モデムC ++を使用すると、メモリ管理の問題ははるかに少なくなりますが、大規模なチームの全員が正しく管理できると信頼できます。費用/時間は何ですか：

• トレーニング（多くのプログラマーが問題をよく理解していない）
• メモリ管理の問題を見つけるためのコードレビュー
• メモリ管理の問題のデバッグ
• アプリの一部のバグは、アプリの無関係な部分のメモリ管理の問題が原因である可能性があることに常に留意する必要があります。

そのため、「実行」に費やす時間だけでなく、これは大規模プロジェクトの問題です。

ブーストライブラリとTR1ライブラリをよく使用しますが、厳密な意味でのメモリ管理（新規/削除）は問題になりません。一方、C ++でのメモリ割り当ては安価ではなく、これらの派手な共有ポインターが作成される場所に注意する必要があります。最終的には、ワークスペースを頻繁に使用するか、スタックベースのメモリを操作します。一般に、私はそれが主に設計上の問題であり、実装上の問題ではないと言うでしょう。

クライアントとしてどれくらい時間がかかりますか？ほんの少しです コンテナがライフタイムと参照を管理するとき、それは非常に簡単です。imo、手動の参照カウントよりもはるかに簡単であり、使用するコンテナをドキュメントとして考慮すると、コンパイラが適切に設計されたタイプセーフシステムで無効な所有権移転を実行するのを便利に防止するため、実質的に透過的です。

（クライアントとして）私が費やす時間のほとんどは、他のAPIからの型を含むために費やされるため、プログラムのコンテキスト内でうまく機能します。例：これは私のThirdPartyFontコンテナーであり、これらの機能をサポートし、この方法で破壊を実装し、この方法で参照をカウントし、この方法でコピーし、そして...を実装します。これらの構造の多くは適切な場所に配置する必要があり、多くの場合、それらを配置する論理的な場所です。それを時間として含めるかどうかはあなたの定義に依存します（とにかく、これらのapiとインターフェースをとるときに実装が存在する必要がありますか？）。

その後、メモリと所有権を考慮する必要があります。下位レベルのシステムでは、それは適切で必要ですが、物事をどのように移動させるかを実装するには、ある程度の時間と足場が必要です。これは低レベルのシステムの要件なので、私はそれを苦痛とは思わない。所有権、管理、責任が明らかです。

したがって、不透明型を使用するCベースのAPIに向けることができます：コンテナを使用すると、これらの不透明型のライフタイムの管理とコピーの小さな実装の詳細をすべて抽象化でき、最終的にリソース管理が非常に簡単になり、時間、欠陥、実装を削減します。

これらを使用するのは非常に簡単です-問題（GCから来る）は、リソースの寿命を考慮する必要があることです。間違えた場合、解決に時間がかかることがあります。明示的なライフタイム管理の学習と統合は、（すべての人ではなく）比較すると理解しやすいほど複雑です。これが本当のハードルです。ライフタイムの制御と適切なソリューションの使用に慣れたら、リソースのライフタイムを管理するのは非常に簡単です。それは私の一日の重要な部分ではありません（難しいバグが入り込んでいない限り）。

コンテナ（自動/共有ポインタ）を使用していない場合は、苦痛を訴えているだけです。

私は自分のライブラリを実装しました。それらを実装するには時間がかかりますが、ほとんどの人は再利用します（通常は良い考えです）。

あなたは手動でメモリを解放し、ファイルを閉じなければならないようなものですか？そうだとすれば、特に「メモリ管理」だけでなく「リソース管理」にそれを一般化した場合、私が使用した他のほとんどの言語よりも少なく、通常は少ないと言えます。その意味で、実際には、C ++はJavaやC＃よりも手動のリソース管理が少なくて済むと思います。

これは主に、リソース（メモリなど）の破壊を自動化するデストラクタが原因です。通常、C ++でリソースを手動で解放/破棄する必要があるのは、vlowレベルのデータ構造（ほとんどの人が行う必要のないもの）を実装している場合、または少し時間を費やしているC APIを使用している場合のみです手動で解放/破棄/クローズする必要があるCリソースをRAII準拠のC ++ラッパーにラップします。

もちろん、ユーザーが画像編集ソフトウェアで画像を閉じるように要求した場合、コレクションなどから画像を削除する必要があります。しかし、このコンテキストで重要な種類の「メモリ」または「リソース」管理としてカウントされないことを願っています。その時点でそのイメージに関連付けられているメモリを解放する場合、それはほとんどの言語で必要です。ただし、コレクションから画像を削除するだけで、残りは画像デストラクタが処理します。

一方、たとえばJavaやC＃と比較すると、そこでファイルを手動で閉じたり、ソケットを手動で切断したり、オブジェクト参照をnullに設定してガベージコレクションできるようにしなければならないことがよくあります。これらの言語でのリソース管理。C ++ではunlock、ミューテックスがスコープ外になると、ミューテックスロッカーが自動的にミューテックスを行うため、手動でミューテックスを使用する必要さえありません。たとえば、C ++で次のようなことを行う必要はありません。

System.IO.StreamReader file = new System.IO.StreamReader(path);
try
{
    file.ReadBlock(buffer, index, buffer.Length);
}
catch (System.IO.IOException e)
{
    ...
}
finally
{
    if (file != null)
        file.Close();
}

C ++でファイルを手動で閉じるようなことをする必要はありません。結果としてスコープ外に出た場合でも、通常の実行パスまたは例外的な実行パスの場合でも、スコープから出た瞬間に自動的に閉じます。のようなメモリ関連リソースについても同様ですstd::vector。file.Close()上記のようなコードは、特にfinallyブロックのコンテキストでは、C ++に関する考え方全体がそれを自動化するときに手動でローカルリソースを解放する必要があることを示唆しているため、しばしば眉をひそめます。

手動のメモリ管理に関しては、Cが最大、Java / C＃が中程度、C ++が最小のいずれかを必要とすると思います。C ++を習得するのは非常に難しい言語なので、C ++を使用することに少し恥ずかしがる理由はたくさんありますが、メモリ管理はその1つではありません。それどころか、私は実際、この一面で最も簡単な言語の1つだと思います。

もちろん、C ++を使用すると、手動でメモリを割り当てoperator delete/delete[]、手動でメモリを解放することができます。また、あなたは次のようにC関数を使用することができますmallocし、free。しかし、それは、人々が信用を与えるずっと前に時代遅れになったと思う種類の古代スタイルのコーディング慣行です。ですから、「モダンC ++」がリソース管理を自動化すると言うのはフェアではないと思います。そうしないと、例外安全性を実際に取得できません。90年代前半の多くの見当違いの開発者が、オブジェクトのあるCのようにC ++を使用しようとし、多くの場合例外処理を完全に無視し、そのように使用されることはありませんでした。実際に常に使用することを意図した方法でC ++を使用する場合、メモリ管理は完全に自動化され、通常は手動で処理する必要のある（または処理する必要のある）ことはほとんどありません。

チームのシニアテクニカルリードに依存します。一部の企業（鉱山を含む）では、スマートポイナーという概念はありません。それは派手と見なされます。そのため、人々は単に削除をあらゆる場所に配置し、2か月ごとにメモリリークを修正するためのドライブがあります。削除ステートメントの新しい波が至る所に到着します。ですから、会社とそこで働く人々の種類に依存します。