C ++プログラマーが「新規」の使用を最小限に抑える必要があるのはなぜですか？

私がつまずいスタックオーバーフロー質問のstd ::リストを使用しているときのstd ::文字列を使用してメモリリーク<はstd :: string>に、そしてコメントの一つは、この言います：

使用を中止newそんなに。どこで新しいものを使ったのか、私にはわかりません。C ++では値によってオブジェクトを作成できます。これは、この言語を使用することの大きな利点の1つです。
すべてをヒープに割り当てる必要はありません。Javaプログラマーの
ように考えるのをやめます。

それが何を意味するのかよくわかりません。

C ++でオブジェクトをできるだけ頻繁に値で作成する必要があるのはなぜですか。また、内部的にどのような違いがありますか？
答えを誤解しましたか？

広く使用されている2つのメモリ割り当て技術があります。自動割り当てと動的割り当てです。通常、それぞれに対応するメモリ領域があります。スタックとヒープです。

スタック

スタックは常に順次方式でメモリを割り当てます。逆の順序でメモリを解放する必要があるため、これを行うことができます（先入れ先出し、FILO）。これは、多くのプログラミング言語におけるローカル変数のメモリ割り当て手法です。最小限の簿記が必要であり、割り当てる次のアドレスが暗黙的であるため、非常に高速です。

C ++では、スコープの最後でストレージが自動的に要求されるため、これは自動ストレージと呼ばれます。現在のコードブロック（を使用して区切られた{}）の実行が完了するとすぐに、そのブロック内のすべての変数のメモリが自動的に収集されます。これは、デストラクタが呼び出されてリソースをクリーンアップする瞬間でもあります。

ヒープ

ヒープにより、より柔軟なメモリ割り当てモードが可能になります。簿記はより複雑で、割り当ては遅くなります。暗黙的な解放ポイントはないため、deleteor delete[]（freeC）を使用して手動でメモリを解放する必要があります。ただし、暗黙的なリリースポイントがないことは、ヒープの柔軟性の鍵です。

ダイナミックアロケーションを使用する理由

ヒープの使用が遅く、メモリリークやメモリの断片化につながる可能性がある場合でも、動的割り当ての制限は少ないため、完全に適切な使用例があります。

ダイナミックアロケーションを使用する2つの主な理由：

• コンパイル時に必要なメモリ量がわかりません。たとえば、テキストファイルを文字列に読み取る場合、通常、ファイルのサイズがわからないため、プログラムを実行するまで、割り当てるメモリ量を決定できません。

• 現在のブロックを終了した後も存続するメモリを割り当てたい。たとえばstring readfile(string path)、ファイルの内容を返す関数を記述したい場合があります。この場合、スタックがファイルの内容全体を保持できたとしても、関数から戻り、割り当てられたメモリブロックを保持することはできません。

ダイナミックアロケーションが不要なことが多い理由

C ++には、デストラクターと呼ばれるきちんとした構成があります。このメカニズムでは、リソースの有効期間を変数の有効期間に合わせることで、リソースを管理できます。この手法はRAIIと呼ばれ、C ++の際立ったポイントです。リソースをオブジェクトに「ラップ」します。 std::string完璧な例です。このスニペット：

int main ( int argc, char* argv[] )
{
    std::string program(argv[0]);
}

実際には、可変量のメモリを割り当てます。std::stringオブジェクトはヒープとそのデストラクタで解放し、それを使用してメモリを割り当てます。この場合は、リソースを手動で管理する必要はなく、動的メモリ割り当てのメリットが得られます。

特に、このスニペットでは、

int main ( int argc, char* argv[] )
{
    std::string * program = new std::string(argv[0]);  // Bad!
    delete program;
}

不要な動的メモリ割り当てがあります。このプログラムでは、さらにタイピング（！）が必要であり、メモリの割り当てを解除し忘れるリスクがあります。これには明らかな利点はありません。

自動ストレージをできるだけ頻繁に使用する理由

基本的に、最後の段落はそれを要約します。自動ストレージをできるだけ頻繁に使用すると、プログラムが次のようになります。

• 入力が速くなります。
• 実行すると速くなります。
• メモリ/リソースリークが発生しにくい。

ボーナスポイント

参照された質問には、追加の懸念があります。特に、次のクラス：

class Line {
public:
    Line();
    ~Line();
    std::string* mString;
};

Line::Line() {
    mString = new std::string("foo_bar");
}

Line::~Line() {
    delete mString;
}

実際には、次のものよりも使用するのがはるかに危険です。

class Line {
public:
    Line();
    std::string mString;
};

Line::Line() {
    mString = "foo_bar";
    // note: there is a cleaner way to write this.
}

その理由はstd::string、コピーコンストラクタを適切に定義しているからです。次のプログラムを検討してください。

int main ()
{
    Line l1;
    Line l2 = l1;
}

元のバージョンを使用deleteすると、同じプログラムで2回使用されるため、このプログラムはおそらくクラッシュします。修飾されたバージョンを使用して、各Lineインスタンスが独自の文字列所有するインスタンスを、それ自体のメモリを有する各両方は、プログラムの終了時に解放されます。

その他の注意事項

上記のすべての理由により、RAIIの広範な使用はC ++でのベストプラクティスと見なされます。ただし、すぐには明らかではない追加の利点があります。基本的に、それはその部分の合計よりも優れています。メカニズム全体が構成しますます。それはスケーリングします。

Lineクラスをビルディングブロックとして使用する場合：

 class Table
 {
      Line borders[4];
 };

その後

 int main ()
 {
     Table table;
 }

4つのstd::stringインスタンス、4つのLineインスタンス、1つのTableインスタンス、およびすべての文字列の内容を割り当て、すべてが自動的に解放されます。

スタックはより高速でリーク防止であるため

C ++では、特定の関数内のすべてのローカルスコープオブジェクトに、スタック上にスペースを割り当てるために1つの命令しかかかりません。そのメモリをリークすることは不可能です。そのコメントは、「ヒープではなくスタックを使用する」のようなことを意図した（または意図したはずの）コメントです。

なぜ複雑なのか。

まず、C ++はガベージコレクションされません。したがって、すべての新規に対して、対応する削除が必要です。この削除に失敗すると、メモリリークが発生します。さて、このような単純なケースでは：

std::string *someString = new std::string(...);
//Do stuff
delete someString;

これは簡単です。しかし、「Do stuff」が例外をスローするとどうなりますか？エラー：メモリリーク。「何かをする」という問題がreturn早期に発生するとどうなりますか？エラー：メモリリーク。

そして、これは最も単純なケースです。あなたがたまたまその文字列を誰かに返した場合、今度は彼らはそれを削除しなければなりません。そして、それを引数として渡した場合、それを受け取った人はそれを削除する必要がありますか？いつ削除すべきですか？

または、これを行うことができます：

std::string someString(...);
//Do stuff

いいえdelete。オブジェクトは「スタック」に作成され、スコープ外になると破棄されます。オブジェクトを返して、その内容を呼び出し元の関数に転送することもできます。オブジェクトを関数に渡すことができます（通常、参照またはconst-referenceとして：）void SomeFunc(std::string &iCanModifyThis, const std::string &iCantModifyThis)。

すべてなしnewとdelete。誰がメモリを所有しているか、誰がメモリを削除する責任があるかは問題ではありません。もしあなたがそうするなら：

std::string someString(...);
std::string otherString;
otherString = someString;

otherStringのデータのコピーがあることがわかりsomeStringます。これはポインタではありません。別のオブジェクトです。それらはたまたま同じ内容を持っているかもしれませんが、他に影響を与えることなく一方を変更できます：

someString += "More text.";
if(otherString == someString) { /*Will never get here */ }

アイデアを参照してください？

によって作成されたオブジェクトは、new最終的deleteにリークしないようにする必要があります。デストラクタは呼び出されず、メモリは解放されません。C ++にはガベージコレクションがないため、問題があります。

値によって（つまり、スタック上に）作成されたオブジェクトは、スコープから外れると自動的に消滅します。デストラクタ呼び出しはコンパイラによって挿入され、メモリは関数が戻るときに自動的に解放されます。

スマートポインタが好きunique_ptr、shared_ptrぶら下がっている参照の問題を解決しコーディング規則が必要であり、他の潜在的な問題（コピー可能性、参照ループなど）があります。

また、マルチスレッドの多いシナリオでnewは、スレッド間の競合のポイントになります。使いすぎるとパフォーマンスに影響する可能性がありますnew。各スレッドには独自のスタックがあるため、スタックオブジェクトの作成は、定義上、スレッドローカルです。

値オブジェクトの欠点は、ホスト関数が戻るとオブジェクトが死ぬことです。値によるコピー、戻り、または移動によってのみ、それらへの参照を呼び出し元に戻すことはできません。

• C ++は独自のメモリマネージャを採用していません。C＃、Javaなどの他の言語には、メモリを処理するガベージコレクターがあります。
• C ++の実装は通常、オペレーティングシステムルーチンを使用してメモリを割り当てます。新規/削除が多すぎると、使用可能なメモリが断片化する可能性があります
• どのアプリケーションでも、メモリが頻繁に使用されている場合は、メモリを事前に割り当てて、不要になったときに解放することをお勧めします。
• メモリ管理が不適切だと、メモリリークが発生する可能性があり、追跡が非常に困難になります。したがって、関数のスコープ内でスタックオブジェクトを使用することは、実証済みの手法です。
• スタックオブジェクトを使用する場合の欠点は、関数の戻り、関数への受け渡しなどでオブジェクトの複数のコピーが作成されることです。ただし、スマートコンパイラはこれらの状況を十分に認識しており、パフォーマンスのために最適化されています。
• メモリが2つの異なる場所で割り当てられて解放される場合、C ++では本当に退屈です。リリースの責任は常に問題であり、ほとんどの場合、一般的にアクセス可能なポインター、スタックオブジェクト（可能な限り最大）、auto_ptr（RAIIオブジェクト）などの手法に依存しています
• 最良のことは、メモリを制御でき、最悪の場合は、アプリケーションに不適切なメモリ管理を採用した場合、メモリを制御できないことです。メモリの破損が原因で発生するクラッシュは最も厄介で、追跡が困難です。

新しいものをできるだけ少なくするためのいくつかの重要な理由を見逃しているようです。

オペレーターのnew実行時間は非決定的です

呼び出しnewによって、OSが新しい物理ページをプロセスに割り当てる場合とそうでない場合があります。頻繁に行う場合、これは非常に遅くなる可能性があります。または、適切なメモリロケーションがすでに準備されている可能性があります。プログラムが一貫性のある予測可能な実行時間を必要とする場合（リアルタイムシステムやゲーム/物理シミュレーションなど）new、タイムクリティカルなループを回避する必要があります。

演算子newは暗黙的なスレッド同期です

はい、あなたは私に聞いた、あなたのOSはあなたのページテーブルが一貫していることを確認する必要がある、そしてそれでそのような呼び出しnewはあなたのスレッドが暗黙のミューテックスロックを獲得する原因となる。new多くのスレッドから一貫して呼び出している場合は、実際にスレッドをシリアル化しています（私はこれを32 CPUで実行しており、それぞれnewが数百バイトを取得するためにヒットしています、これはデバッグするためのロイヤルピタでした）。

遅い、断片化、エラーが発生しやすいなどの残りの部分は、すでに他の回答で言及されています。

C ++ 17より前：

結果をスマートポインターでラップしても、微妙なリークが発生しやすいためです。

オブジェクトをスマートポインタでラップすることを覚えている「注意深い」ユーザーを考えてみましょう。

foo(shared_ptr<T1>(new T1()), shared_ptr<T2>(new T2()));

が存在しないため、このコードは危険であるという保証のいずれかということshared_ptrに構築された前のいずれかT1またはT2。したがって、一方が失敗した場合、new T1()またはnew T2()もう一方が成功した後に失敗した場合、最初のオブジェクトはリークさshared_ptrれ、破棄して割り当てを解除するオブジェクトが存在しないためです。

解決策：を使用しますmake_shared。

C ++ 17以降：

これはもはや問題ではありません。C++ 17はこれらの操作の順序に制約を課します。この場合、への各呼び出しのnew()直後に、対応するスマートポインタの構築が続き、その間に他の操作はないようにします。これnew()は、2番目のオブジェクトが呼び出されるまでに、最初のオブジェクトがすでにスマートポインターでラップされていることが保証されているため、例外がスローされた場合のリークを防止します。

C ++ 17によって導入された新しい評価順序の詳細な説明は、別の回答でバリーによって提供されました。

これはC ++ 17 でもまだ問題であることを指摘してくれた@Remy Lebeauに感謝します（それほどではありません）。コンストラクターは制御ブロックの割り当てとスローに失敗する可能性があり、その場合、渡されたポインターは削除されません。shared_ptr

解決策：を使用しますmake_shared。

多くの場合、それは自分の弱点を一般的なルールにまで引き上げる誰かです。演算子を使用してオブジェクトを作成すること自体、何も問題はありませんnew。いくつかの議論があるのは、ある種の規律でそうしなければならないということです。オブジェクトを作成する場合、オブジェクトが確実に破棄されるようにする必要があります。

これを行う最も簡単な方法は、自動ストレージにオブジェクトを作成することです。そのため、C ++は、オブジェクトがスコープ外になったときにそれを破棄することを認識しています。

 {
    File foo = File("foo.dat");

    // do things

 }

ここで、エンドブレースの後にそのブロックから落ちるとfoo、スコープ外であることを確認してください。C ++は自動的にそのdtorを呼び出します。Javaとは異なり、GCがそれを見つけるのを待つ必要はありません。

あなたは書きましたか

 {
     File * foo = new File("foo.dat");

あなたはそれを明示的に一致させたいでしょう

     delete foo;
  }

またはさらに良い、あなたの割り当て File *「スマートポインター」として。気を付けないと漏れの原因になります。

答え自体は、使用しない場合newはヒープに割り当てないという誤った仮定をしています。実際、C ++ではそれがわかりません。ほとんどの場合、メモリの小さな量、たとえば1つのポインタが確実にスタックに割り当てられます。ただし、Fileの実装が次のようなものであるかどうかを検討してください。

  class File {
    private:
      FileImpl * fd;
    public:
      File(String fn){ fd = new FileImpl(fn);}

その後、FileImplう、まだスタックに割り当てられます。

そして、はい、あなたは持っている方がいいでしょう

     ~File(){ delete fd ; }

クラスでも。これがないと、ヒープに割り当てをまったく行わなかったとしても、ヒープからメモリがリークします。

new()使用すべきではない少し可能な限り。できるだけ慎重に使用する必要があります。そして、それは実用主義によって要求されるのと同じくらい必要な頻度で使われるべきです。

暗黙的な破棄に依存するスタック上のオブジェクトの割り当ては、単純なモデルです。オブジェクトの必要なスコープがそのモデルに適合する場合、NULLポインターのnew()関連付けられたdelete()チェックを使用して、を使用する必要はありません。スタックに短期間のオブジェクトがたくさんある場合は、ヒープの断片化の問題を減らす必要があります。

ただし、オブジェクトの有効期間が現在のスコープを超えて拡張する必要new()がある場合は、正しい答えです。いつ、どのように呼び出すか、およびdelete()NULLポインターの可能性に注意を払い、削除されたオブジェクトと、ポインターの使用に伴うその他すべての問題を使用していることを確認してください。

newを使用すると、オブジェクトがヒープに割り当てられます。通常、拡張が予想される場合に使用されます。次のようなオブジェクトを宣言すると、

Class var;

スタックに配置されます。

ヒープに配置したオブジェクトに対して、常にnewでdestroyを呼び出す必要があります。これにより、メモリリークが発生する可能性があります。スタックに配置されたオブジェクトは、メモリリークの傾向がありません！

ヒープの過剰使用を回避する1つの注目すべき理由は、パフォーマンスです。特に、C ++で使用されるデフォルトのメモリ管理メカニズムのパフォーマンスに関係しています。割り当ては非常に簡単な場合もnewありdeleteますが、厳密な順序なしでサイズが不均一なオブジェクトを多数実行すると、メモリの断片化が発生するだけでなく、割り当てアルゴリズムが複雑になり、特定の場合にパフォーマンスが完全に失われる可能性があります。

これは、解決のために作成されたメモリプールの問題であり、必要に応じてヒープを使用しながら、従来のヒープ実装の固有の欠点を軽減することができます。

ただし、問題を完全に回避するためには、なお良いでしょう。スタックに配置できる場合は、それを実行してください。

ポスターはYou do not have to allocate everything on theheapでなく、言うことを意図したものだと思いますstack。

基本的にオブジェクトはスタックに割り当てられます（もちろん、オブジェクトサイズが許す場合）。ヒープ割り当てベースの割り当てではなく、スタック割り当てのコストが安いため、アロケータによるかなりの作業が伴い、冗長性が追加されます。ヒープに割り当てられたデータを管理します。

私は新しい「多すぎる」を使用するという考えに反対する傾向があります。元の投稿者がシステムクラスでnewを使用するのは少しばかげています。（int *i; i = new int[9999];？本当に？int i[9999];は、はるかに明確です。）私は、それがコメンターのヤギを獲得したものだと思います。

システムオブジェクトを使用している場合、まったく同じオブジェクトへの複数の参照が必要になることは非常にまれです。値が同じである限り、それだけが重要です。また、システムオブジェクトは通常、メモリ内で多くの領域を占有しません。（文字列内の文字ごとに1バイト）。そして、もしそうなら、ライブラリはそのメモリ管理を考慮に入れるように設計されるべきです（それらが上手く書かれていれば）。これらの場合（コード内の1つまたは2つのニュースを除くすべて）、newは実質的に無意味であり、バグの混乱と潜在的な可能性をもたらすだけです。

ただし、独自のクラス/オブジェクト（たとえば、元の投稿者のLineクラス）で作業している場合は、メモリフットプリント、データの永続性などの問題について自分で考え始める必要があります。この時点で、同じ値への複数の参照を許可することは非常に重要です。リンクされたリスト、ディクショナリ、グラフなどの構造が可能になります。複数の変数が同じ値を持つだけでなく、メモリ内のまったく同じオブジェクトを参照する必要があります。ただし、Lineクラスにはこれらの要件はありません。そのため、元の投稿者のコードには、実際にはは必要ありませんnew。

2つの理由：

1. この場合は不要です。あなたはあなたのコードを不必要により複雑にしています。
2. ヒープに領域を割り当てます。これは、delete後で記憶する必要があることを意味します。そうしないと、メモリリークが発生します。

new新しいgotoです。

なぜgotoこれほどひどいのかを思い出してください。フロー制御のための強力で低レベルのツールですが、不必要に複雑な方法で使用され、コードの追跡が困難になることがよくありました。さらに、パターンを読み取るのに最も便利で最も簡単なものは、構造化プログラミングステートメント（forまたはwhile）にエンコードされています。最終的な効果はgoto、適切な方法がどこにあるかというコードがかなりまれであるということです。もしあなたがを書きたくなった場合goto、あなたはおそらく悪いことをしています（本当に自分が何をしているかを理解していない限り）。

new似ています—不必要に複雑で読みにくいものにするためによく使用され、エンコードできる最も有用な使用パターンはさまざまなクラスにエンコードされています。さらに、標準クラスがまだない新しい使用パターンを使用する必要がある場合は、それらをエンコードする独自のクラスを作成できます。

私もそれが主張newされるより悪いよりもgotoペアにする必要が原因、newとdelete声明。

のようにgoto、を使用する必要newがあると思われる場合は、おそらく悪いことをしています。特に、必要な動的割り当てをカプセル化することが目的であるクラスの実装の外部でそうしている場合はなおさらです。

主な理由は、ヒープ上のオブジェクトは、単純な値よりも常に使用および管理が難しいためです。読みやすく保守しやすいコードを書くことは、真面目なプログラマーにとって常に最優先事項です。

別のシナリオは、使用しているライブラリが値のセマンティクスを提供し、動的割り当てを不要にすることです。Std::string良い例です。

ただし、オブジェクト指向コードの場合、ポインタを使用newすること（つまり、事前に作成するために使用すること）は必須です。リソース管理の複雑さを単純化するために、スマートポインタなど、それをできるだけ単純にするための数十のツールを用意しています。オブジェクトベースのパラダイムまたはジェネリックパラダイムは、値のセマンティクスを想定してnewおり、他のポスターで述べられているように、必要な数は少ないか、まったくありません。

従来のデザインパターン、特にGoF本で言及さnewれているものは、典型的なOOコードであるため、多く使用されます。

上記のすべての正解に対するもう1つのポイントは、どのようなプログラミングを行っているかによって異なります。たとえば、カーネルがWindowsで開発されている->スタックは厳しく制限されており、ユーザーモードのようにページフォールトを実行できない場合があります。

このような環境では、新しい、またはCのようなAPI呼び出しが優先され、必要になることさえあります。

もちろん、これはルールの例外にすぎません。

newオブジェクトをヒープに割り当てます。それ以外の場合、オブジェクトはスタックに割り当てられます。2つの違いを調べてください。