長年のC＃プログラマーとして、最近、Resource Acquisition Is Initialization（RAII）の利点について詳しく知るようになりました。特に、C＃のイディオムは次のとおりです。

using (var dbConn = new DbConnection(connStr)) {
    // do stuff with dbConn
}

C ++に相当するものがあります。

{
    DbConnection dbConn(connStr);
    // do stuff with dbConn
}

つまりDbConnection、usingブロックのようにリソースの使用を囲むことを覚えておくことは、C ++では不要です。これは、C ++の大きな利点のようです。あなたはタイプのインスタンスメンバを持つクラスを考えるとき、これは、より説得力があるDbConnectionたとえば、

class Foo {
    DbConnection dbConn;

    // ...
}

C＃では、Foo IDisposableを次のように実装する必要があります。

class Foo : IDisposable {
    DbConnection dbConn;

    public void Dispose()
    {       
        dbConn.Dispose();
    }
}

さらに悪い何、のすべてのユーザーがFoo囲む覚えておく必要があるだろうFooにusingように、ブロック：

   using (var foo = new Foo()) {
       // do stuff with "foo"
   }

今、C＃とそのJavaのルーツを見て、私は疑問に思っています... Javaの開発者は、ヒープを優先してスタックを放棄し、RAIIを放棄したときに放棄したものを完全に感謝しましたか？

（同様に、StroustrupはRAIIの重要性を完全に評価しましたか？）

今、C＃とそのJavaのルーツを見て、私は疑問に思っています... Javaの開発者は、ヒープを優先してスタックを放棄し、RAIIを放棄したときに放棄したものを完全に感謝しましたか？

（同様に、StroustrupはRAIIの重要性を完全に評価しましたか？）

GoslingがJavaの設計時にRAIIの重要性を理解していなかったと確信しています。彼のインタビューでは、ジェネリックと演算子のオーバーロードを除外する理由についてよく話しましたが、決定論的なデストラクタとRAIIについては言及しませんでした。

面白いことに、Stroustrupでさえ、設計時に決定論的なデストラクタの重要性を認識していませんでした。私は引用を見つけることができませんが、あなたが本当にそれに興味があるなら、あなたはここで彼のインタビューの中でそれを見つけることができます：http : //www.stroustrup.com/interviews.html

はい、C＃（および、おそらくJava）の設計者は、決定論的なファイナライズに特に反対しました。1999年から2002年にかけて、アンデルス・ヘイルスベルグに何度も尋ねました。

まず、スタックベースかヒープベースかに基づいたオブジェクトのさまざまなセマンティクスのアイデアは、両方の言語の統一された設計目標に確実に反するものであり、プログラマーをまさにそのような問題から解放することでした。

第二に、利点があることを認めたとしても、簿記にはかなりの実装の複雑さと非効率性が伴います。マネージ言語では、スタックのようなオブジェクトを実際にスタックに配置することはできません。「スタックのようなセマンティクス」と言って、重要な作業に専念する必要があります（値型はすでに十分に難しいので、参照が管理メモリに出入りする複雑なクラスのインスタンスであるオブジェクトについて考えてください）。

そのため、「（ほとんど）すべてがオブジェクトである」プログラミングシステム内のすべてのオブジェクトで決定論的なファイナライズを行いたくありません。そのため、通常追跡されるオブジェクトを確定的なファイナライズを持つオブジェクトから分離するために、プログラマーが制御する構文を導入する必要があります。

C＃には、usingキーワードがあります。これは、C＃1.0になったものの設計のかなり後期に登場しました。全体IDisposableがかなり悲惨であり、ボイラープレートパターンを自動的に適用できるクラスをマークusingするC ++デストラクタ構文~を使用する方がエレガントになるのではないかと思いIDisposableますか？

Javaは、C ++がまったく異なる言語であった1991〜1995年に開発されたことに留意してください。例外（RAIIが必要になった）とテンプレート（スマートポインターの実装が簡単になった）は、「新しい」機能です。ほとんどのC ++プログラマはCから来ており、手動のメモリ管理を行うことに慣れていました。

したがって、Javaの開発者がRAIIを放棄することを意図的に決定したとは思えません。ただし、Javaでは値のセマンティクスではなく参照のセマンティクスを優先することを意図的に決定しました。 決定論的破壊は、参照セマンティクス言語では実装が困難です。

では、なぜ値セマンティクスの代わりに参照セマンティクスを使用するのでしょうか？

それは言語をずっと単純にするからです。

• 間の構文上の区別は必要ありませんFooし、Foo*あるいは間foo.barとはfoo->bar。
• すべての割り当てがポインターのコピーである場合、オーバーロードされた割り当ての必要はありません。
• コピーコンストラクターは必要ありません。（たまに明示的なコピー機能clone()が必要になることがあります。多くのオブジェクトはコピーする必要がないだけです。たとえば、不変なオブジェクトは必要ありません。）
• privateコピーコンストラクタを宣言したりoperator=、クラスをコピー不可にする必要はありません。クラスのオブジェクトをコピーしたくない場合は、コピーする関数を作成しないでください。
• swap機能は必要ありません。（ソートルーチンを記述している場合を除きます。）
• C ++ 0xスタイルの右辺値参照の必要はありません。
• （N）RVOの必要はありません。
• スライスの問題はありません。
• 参照のサイズは固定されているため、コンパイラーはオブジェクトのレイアウトを簡単に決定できます。

参照セマンティクスの主な欠点は、すべてのオブジェクトが潜在的に複数の参照を持っている場合、それをいつ削除するかがわかりにくくなることです。ほとんどの場合、自動メモリ管理が必要です。

Javaは、非決定的ガベージコレクターの使用を選択しました。

GCは決定論的ではありませんか？

はい、できます。たとえば、PythonのC実装は参照カウントを使用します。また、後でrefcountsが失敗するサイクリックガベージを処理するトレースGCを追加しました。

しかし、リカウントは恐ろしく非効率的です。カウントの更新に多くのCPUサイクルが費やされました。さらに悪いことに、これらの更新を同期する必要があるマルチスレッド環境（Javaが設計されたようなもの）では。別のガベージコレクタに切り替える必要があるまでは、nullガベージコレクタを使用する方がはるかに優れています。

Javaは、ファイルやソケットなどの代替不可能なリソースを犠牲にして、一般的なケース（メモリ）を最適化することを選択したと言えます。今日、C ++でのRAIIの採用に照らして、これは間違った選択のように思えるかもしれません。しかし、Javaの対象読者の多くは、これらのことを明示的に閉じることに慣れていたC（または「C with classes」）プログラマーであったことを思い出してください。

しかし、C ++ / CLIの「スタックオブジェクト」はどうでしょうか。

C＃によく似た（元のリンク）の構文糖衣Disposeです。ただし、匿名を作成でき、C ++ / CLIは自動破棄しないため、決定論的破壊の一般的な問題は解決しません。usinggcnew FileStream("filename.ext")

Java7はC＃に似たものを導入しましたusing： try-with-resourcesステートメント

try1つ以上のリソースを宣言する声明。リソースは、プログラムがそれを終了した後に閉じなければならない対象の通りです。try-with-リソース文は、各リソースは、文の最後に閉じられていることを保証します。を実装するすべてのオブジェクトは、実装するjava.lang.AutoCloseableすべてのオブジェクトを含みjava.io.Closeable、リソースとして使用できます...

だから、彼らは意識的にRAIIを実装しないことを選択しなかったか、その間に気が変わったと思います。

Javaには意図的にスタックベースのオブジェクト（値オブジェクトとも呼ばれます）はありません。これらは、そのようなメソッドの最後でオブジェクトを自動的に破壊するために必要です。

これと、Javaがガベージコレクションされるため、確定的なファイナライズは多かれ少なかれ不可能です（例：「ローカル」オブジェクトが他の場所で参照された場合はどうなりますか？ ）。

ただし、ネイティブ（C ++）リソースとやり取りする場合を除き、確定的なファイナライズの必要はほとんどないため、これはほとんどの人にとっては問題ありません。

Javaにスタックベースのオブジェクトがないのはなぜですか？

（プリミティブ以外..）

スタックベースのオブジェクトは、ヒープベースの参照とは異なるセマンティクスを持っているためです。C ++で次のコードを想像してください。それは何をするためのものか？

return myObject;

• 場合はmyObjectローカルスタックベースのオブジェクトである（結果は何かに割り当てられている場合）、コピーコンストラクタが呼び出されます。
• 場合はmyObjectローカルスタックベースのオブジェクトであり、我々は参照を返している、結果は未定義です。
• 場合はmyObjectメンバー/グローバルオブジェクトである（結果は何かに割り当てられている場合）、コピーコンストラクタが呼び出されます。
• 場合はmyObjectメンバー/グローバルオブジェクトであり、我々は参照を返している、参照が返されます。
• myObjectがローカルスタックベースのオブジェクトへのポインタである場合、結果は未定義です。
• 場合はmyObjectメンバー/グローバルオブジェクトへのポインタで、そのポインタが返されます。
• 場合はmyObject、ヒープベースのオブジェクトへのポインタで、そのポインタが返されます。

さて、同じコードはJavaで何をしますか？

return myObject;

• への参照myObjectが返されます。変数がローカル、メンバー、グローバルのいずれでもかまいません。心配するスタックベースのオブジェクトやポインターのケースはありません。

上記は、スタックベースのオブジェクトがC ++のプログラミングエラーの非常に一般的な原因である理由を示しています。そのため、Javaデザイナーはそれらを削除しました。そして、それらがなければ、JavaでRAIIを使用しても意味がありません。

の穴の説明usingが不完全です。次の問題を考慮してください。

interface Bar {
    ...
}
class Foo : Bar, IDisposable {
    ...
}

Bar b = new Foo();

// Where's the Dispose?

私の意見では、RAIIとGCの両方を持たないことは悪い考えでした。それはJavaでファイルを閉じるに来るとき、それはだmalloc()とfree()あそこ。

私はかなり年寄りです。私はそこに行って見たことがあり、何度も頭を打ちました。

私はハースリー・パークで開催された会議で、IBMの少年たちがこの新しいJava言語の素晴らしさを教えてくれました。誰かに尋ねられただけです。彼は私たちがC ++のデストラクタとして知っていることを意味していませんでしたが、ファイナライザもありませんでした（またはファイナライザはありましたが、基本的に機能しませんでした）。これは昔の話で、その時点でJavaはちょっとしたおもちゃの言語であると判断しました。

現在、言語仕様にファイナライザーを追加し、Javaがある程度採用されました。

もちろん、後でGCの速度が大幅に低下したため、ファイナライザーをオブジェクトに配置しないようにみんなに言われました。（ヒープをロックするだけでなく、ファイナライズされるオブジェクトを一時領域に移動する必要があったため、GCがアプリの実行を一時停止したため、これらのメソッドを呼び出すことができませんでした。代わりに、次の直前に呼び出されますGCサイクル）（さらに悪いことに、アプリのシャットダウン時にファイナライザーがまったく呼び出されないことがあります。ファイルハンドルを閉じないことを想像してください）

その後、C＃がありました。MSDNのディスカッションフォーラムでは、この新しいC＃言語の素晴らしさを教えられました。決定論的なファイナライズが行われない理由を誰かが尋ね、MSの少年たちはそのようなものが必要ないことを教えてくれ、アプリの設計方法を変える必要があると言ってから、GCのすばらしさと古いアプリのすべてを教えてくれましたすべての循環参照のために、ゴミであり、決して機能しませんでした。それから彼らは圧力に屈し、私たちが使用できるスペックにこのIDisposeパターンを追加したと言った。その時点で、C＃アプリでの手動メモリ管理にかなり戻ったと思いました。

もちろん、MSの少年たちは後で、彼らが私たちに言ったことはすべて...であることに気づきました。W00t！結局、決定論的なファイナライズは言語に欠けているものであることに気付きました。もちろん、あなたはそれをどこにでも忘れずに置く必要があるので、それでも少し手作業ですが、より良いです。

では、最初から各スコープブロックに使用スタイルのセマンティクスを自動的に配置することができたのに、なぜそうしたのでしょうか。おそらく効率ですが、私は彼らがただ実現しなかったと思うのが好きです。最終的に、.NET（google SafeHandle）のスマートポインターが必要であることに気付いたように、GCは本当にすべての問題を解決すると考えていました。オブジェクトは単なるメモリ以上のものであり、GCは主にメモリ管理を処理するように設計されていることを忘れていました。彼らはGCがこれを処理するという考えに巻き込まれ、あなたがそこに他のものを置くことを忘れていました、オブジェクトはあなたがしばらくそれを削除しなくても問題ではないメモリのブロブではありません。

しかし、元のJavaにfinalizeメソッドがないことは、もう少し多くのものがあると思います-作成したオブジェクトはすべてメモリに関するものであり、他の何か（DBハンドルやソケットなど）を削除したい場合）それからあなたは手動でそれをすると予想されました。

Javaは、多くの手動割り当てでCコードを記述することに慣れている組み込み環境向けに設計されたため、自動解放がないことはそれほど問題ではなかったことを思い出してください。この問題は、スレッドやスタック/ヒープとは関係ありませんでした。おそらくメモリ割り当て（および割り当て解除）を少し簡単にするためだけの問題でした。全体的に、try / finallyステートメントは、おそらくメモリ以外のリソースを処理するのに適した場所です。

だから私見、.NETがJavaの最大の欠陥を単純にコピーした方法は、最大の弱点です。.NETは、優れたJavaではなく、優れたC ++である必要がありました。

「Thinking in Java」および「Thinking in C ++」の著者であり、C ++ Standards CommitteeのメンバーであるBruce Eckelは、多くの分野（RAIIだけでなく）で、GoslingとJavaチームが宿題。

...言語が不快で複雑であり、同時に適切に設計される方法を理解するには、C ++のすべてがハングする主要な設計決定を覚えておく必要があります。 、Cプログラマの大衆をオブジェクトに移動させる方法は、移動を透明にすることであると思われます。C++でCコードを変更せずにコンパイルできるようにするためです。これは大きな制約であり、常にC ++の最大の強みであり、その悩みの種でした。これが、C ++をこれまでと同じように成功させ、複雑なものにしました。

また、C ++を十分に理解していないJavaデザイナーをだましました。たとえば、オペレーターのオーバーロードはプログラマーが適切に使用するには難しすぎると考えていました。C ++にはスタック割り当てとヒープ割り当ての両方があり、すべての状況を処理してメモリリークを引き起こさないように演算子をオーバーロードする必要があるため、これは基本的にC ++に当てはまります。確かに難しい。ただし、Javaには単一のストレージ割り当てメカニズムとガベージコレクターがあり、C＃で示されたように（ただしJavaに先行するPythonで既に示されていたように）演算子のオーバーロードを簡単にします。しかし、長年の間、Javaチームからの一部の意見は「演算子のオーバーロードは複雑すぎる」というものでした。これと、誰かが明らかにしなかった他の多くの決定」

他にもたくさんの例があります。プリミティブは「効率のために含まれなければなりませんでした」。正しい答えは、「すべてがオブジェクト」に忠実であり、効率が必要な場合に低レベルのアクティビティを実行するためのトラップドアを提供することです（これにより、ホットスポットテクノロジーが最終的に物事をより効率的にすることも可能になります）持ってる）。ああ、超越関数を計算するために直接浮動小数点プロセッサを使用できないという事実（代わりにソフトウェアで行われます）。私はこのような問題についてはできる限り書きましたが、私が聞く答えは常に「これはJavaのやり方だ」という効果に対するトートロジー的な回答でした。

ジェネリックがどれほどひどく設計されているかについて書いたとき、「Javaで行われた以前の（悪い）決定と下位互換性がなければならない」と同じ反応を得ました。最近、ますます多くの人々がジェネリックの十分な経験を積んで、本当に使いにくいことがわかりました。実際、C ++テンプレートははるかに強力で一貫性があります（コンパイラエラーメッセージが許容されるようになったため、使いやすくなりました）。人々は具体化を真剣に考えさえしてきました-役に立つが、自主的な制約によって損なわれるデザインにそれほど大きな凹みを入れない何か。

リストは、退屈なところまで続きます...

最良の理由は、ここでのほとんどの答えよりもはるかに単純です。

スタックに割り当てられたオブジェクトを他のスレッドに渡すことはできません。

停止して、それについて考えてください。考え続けてください...今、誰もがRAIIに熱心になったとき、C ++にはスレッドがありませんでした。あまりにも多くのオブジェクトを渡すと、Erlang（スレッドごとに別々のヒープ）でさえうるさくなります。C ++はC ++ 2011でのみメモリモデルを取得しました。これで、コンパイラの「ドキュメント」を参照することなく、C ++の同時実行性についてほとんど推論できます。

Javaは（ほぼ）初日から複数のスレッド用に設計されました。

Stroustrupがスレッドを必要としないことを保証する「C ++プログラミング言語」の古いコピーをまだ持っています。

2番目の痛みを伴う理由は、スライスを避けることです。

C ++では、より汎用的な低レベルの言語機能（スタックベースのオブジェクトで自動的に呼び出されるデストラクタ）を使用して、高レベルの機能（RAII）を実装します。あまりにも好き。むしろ、特定のニーズに合わせて特定の高レベルのツールを設計し、既製の言語に組み込まれたプログラマーに提供します。このような特定のツールの問題は、カスタマイズが不可能な場合が多いことです（そのため、学習しやすくなっています）。小さいブロックから構築する場合、時間の経過とともにより良いソリューションが生まれる可能性がありますが、高レベルの組み込みのコンストラクトしかない場合は、これはあまりありません。

ええ、私は（実際にはそこにはいませんでした...）それは、言語を使いやすくすることを目的とした、慎重な決定であったと思いますが、私の意見では、それは悪い決定でした。繰り返しになりますが、私は通常、C ++がプログラマーにチャンスを与え、自分自身をロールするという哲学を好むため、少し偏見があります。

Disposeメソッドを使用して、C＃でこれに相当する大まかなコードを既に呼び出しています。Javaにもありfinalizeます。 注： Javaのファイナライズは非決定的であり、とは異なることを認識しています。Dispose両方ともGCとともにリソースをクリーニングする方法があることを指摘しています。

ただし、オブジェクトを物理的に破棄する必要があるため、C ++の方が苦痛になります。C＃やJavaのような高レベル言語では、ガベージコレクターを使用して、参照がなくなったときにクリーンアップします。C ++のDBConnectionオブジェクトに不正な参照またはそのポインターがないという保証はありません。

はい

私のような他の人がより明確なよりサンドボックス化された言語を好むC ++の低レベルのパワー、制御、および純度のようないくつかは、おそらく好みに帰着します。