最終的にデストラクタと概念的な違いは何ですか？

まず、C ++に「最終的に」コンストラクトがない理由をよく知っていますか？しかし、別の質問に関する長期にわたるコメントの議論は、別の質問を正当化するようです。

それを除けば問題から、finallyC＃やJavaで基本的に一度だけ存在することができます（== 1）の範囲および単一のスコープあたりが（== n）を複数持つことができますC ++デストラクタ、私は、彼らは基本的に同じものだと思います。（技術的な違いがいくつかあります。）

しかし、別のユーザーは次のように主張しました：

...私は、dtorは本質的に（リリースセマティクス）のツールであり、最終的には本質的に（コミットセマンティクス）のツールであると言っていました。理由がわからない場合は、finallyブロックで例外を互いの上にスローするのが正当である理由と、デストラクタが例外でない理由を検討してください。（ある意味、それはデータとコントロールの関係です。デストラクタはデータを解放するためのものであり、最終的にはコントロールを解放するためのものです。それらは異なります。C++がそれらを結び付けるのは残念です。）

誰かがこれを解決できますか？

• トランザクション（try）
• エラー出力/応答（catch）
• 外部エラー（throw）
• プログラマーエラー（assert）
• ロールバック（最も近いものは、ネイティブにサポートする言語のスコープガードかもしれません）
• リソースの解放（デストラクタ）
• その他のトランザクションに依存しない制御フロー（finally）

finallyその他のトランザクションに依存しない制御フローよりも良い説明を思い付くことができません。特にデストラクタとの両方を含む理論的言語では、トランザクションとエラー回復の考え方のコンテキストで、必ずしも高レベルの概念に直接マップするわけではありませんfinally。

私に最も本質的に欠けているのは、外部副作用をロールバックする概念を直接表す言語機能です。Dのような言語のスコープガードは、その概念を表現することに近い、私が考えることができる最も近いものです。制御フローの観点から、特定の関数のスコープでのロールバックでは、例外的なパスを通常のパスと区別する必要があります。同時に、トランザクションが失敗した場合に関数によって引き起こされる副作用の暗黙的なロールバックを自動化する必要がありますが、トランザクションが成功したときではありません。たとえば、succeededデストラクタでのロールバックロジックを防ぐために、tryブロックの最後にブール値をtrueのような値に設定すると、デストラクタで簡単に実行できます。しかし、これはこれを行うためのかなり遠回りの方法です。

それはそれほど節約しないように思えるかもしれませんが、副作用の逆転は正しいことを行うのが最も難しいことの1つです（例：例外に対して安全なジェネリックコンテナを書くことを非常に難しくするもの）。

ある意味では、フェラーリとトランジットの両方を使用して、さまざまな用途向けに設計されているにもかかわらず、1パイントのミルクを求めて店を挟むことができます。

try / finallyコンストラクトをすべてのスコープに配置し、finallyブロック内のすべてのスコープ定義変数をクリーンアップして、C ++デストラクタをエミュレートできます。これは、概念的にはC ++が行うことです。変数がスコープから外れると（つまり、スコープブロックの最後に）、コンパイラは自動的にデストラクタを呼び出します。ただし、各スコープでtryが最初で最後に最後になるように、try / finallyを調整する必要があります。また、各オブジェクトの標準を定義して、finallyブロックで呼び出す状態をクリーンアップするために使用する特定の名前のメソッドを持たせる必要がありますが、言語が提供する通常のメモリ管理はそのままにしておくことができます好きなときに空になったオブジェクトをクリーンアップします。

ただし、これを行うのはきれいではありません。また、.NETはIDisposeを手動で管理するデストラクタとして導入し、ブロックを使用して手動での管理をやや簡単にしようとしましたが、それでも実際にはやりたくないことです。

私の観点からの主な違いは、c ++のデストラクタが、 割り当てられたリソースを解放するための暗黙的なメカニズム（自動的に呼び出される）である一方で、try ... 最終的にそれを行う明示的なメカニズムとして使用できることです。

C ++プログラムでは、プログラマーは割り当てられたリソースを解放する責任があります。これは通常、クラスのデストラクタで実装され、変数がスコープ外に出たとき、または削除が呼び出されたときにすぐに実行されます。

c ++の場合、クラスのローカル変数newは、例外が発生したときにデストラクタによって暗黙的に解放されるインスタンスのリソースを使用せずに作成されます。

// c++
void test() {
    MyClass myClass(someParameter);
    // if there is an exception the destructor of MyClass is called automatically
    // this does not work with
    // MyClass* pMyClass = new MyClass(someParameter);

} // on test() exit the destructor of myClass is implicitly called

Java、c＃、および自動メモリ管理を備えた他のシステムでは、システムガベージコレクターがクラスインスタンスが破棄されるタイミングを決定します。

// c#
void test() {
    MyClass myClass = new MyClass(someParameter);
    // if there is an exception myClass is NOT destroyed so there may be memory/resource leakes

    myClass.destroy(); // this is never called
}

暗黙的なメカニズムはないため、try finallyを使用して明示的にプログラムする必要があります

// c#
void test() {
    MyClass myClass = null;

    try {
        myClass = new MyClass(someParameter);
        ...
    } finally {
        // explicit memory management
        // even if there is an exception myClass resources are freed
        myClass.destroy();
    }

    myClass.destroy(); // this is never called
}

質問としてこれを投稿してくれてありがとう。:)

私はそのデストラクタと言って、finally概念的に異なっていました：

• デストラクタはリソース（データ） を解放するためのものです
• finally呼び出し元に戻るためです（コントロール）

この仮想的な擬似コードを考えてみましょう：

try {
    bar();
} finally {
    logfile.print("bar has exited...");
}

finallyここでは、リソース管理の問題ではなく、制御の問題を完全に解決しています。
さまざまな理由により、デストラクタでこれを行うのは意味がありません。

• 「取得」または「作成」されているものはない
• ログファイルに印刷する障害があろうないリソースリーク、データ破壊等（ここではログファイルを別の場所でプログラムにフィードバックされていないと仮定して）をもたらします
• logfile.print失敗することは正当ですが、破壊は（概念的に）失敗することはできません。

ここに別の例を示します。今回はJavascriptのようなものです。

var mo_document = document, mo;
function observe(mutations) {
    mo.disconnect();  // stop observing changes to prevent re-entrance
    try {
        /* modify stuff */
    } finally {
        mo.observe(mo_document);  // continue observing (conceptually, this can fail)
    }
}
mo = new MutationObserver(observe);
return observe();

上記の例でも、解放するリソースはありません。
実際、finallyブロックは目標を達成するために内部的にリソースを獲得していますが、失敗する可能性があります。したがって、デストラクタを使用することは意味がありません（Javascriptがある場合）。

一方、この例では：

b = get_data();
try {
    a.write(b);
} finally {
    free(b);
}

finallyリソースを破壊していbます。これはデータの問題です。問題は、呼び出し元に制御をきれいに戻すことではなく、リソースリークを回避することです。
失敗は選択肢ではなく、（概念的に）発生することはありません。
のすべてのリリースbは必然的に買収とペアになり、RAIIを使用することは理にかなっています。

言い換えると、どちらかをシミュレートするためにどちらかを使用できるからといって、両方が1つの同じ問題であること、または両方が両方の問題の適切な解決策であることを意味しません。

k3bの答えは本当にうまく表現しています：

c ++のデストラクタは、割り当てられたリソースを解放するための暗黙的なメカニズム（自動的に呼び出されます）であり、try ...は最終的にそれを行う明示的なメカニズムとして使用できます。

「リソース」については、Jon Kalb：RAIIはResponsibility Acquisition Is Initializationを意味します。

とにかく、暗黙的vs明示的に関しては、これは本当にそれのようです：

• d'torは、オブジェクトの有効期間が終了する（暗黙的に-スコープの終わりと一致することが多い）ときに、どの操作が行われるかを定義するツールです。
• 最終ブロックは、明示的に-スコープの終わりにどの操作を行うかを定義するツールです。
• さらに、技術的には、常に最終的にスローすることが許可されていますが、以下を参照してください。

概念的な部分については以上だと思います...

...現在、いくつかの興味深い詳細があります。

• try / catch /最後にありますということに欠けているNOがfault、例外的なスコープ終了の場合にのみ実行されるコードを実行するブロックがます。
• デストラクタは、最終的には機械を構築するために使用することができます-を参照しSCOPE_EXIT、SCOPE_FAILそしてSCOPE_SUCCESS 愚かライブラリで。Andrei Alexandrescu：C ++ / Declarative Control Flowのエラー処理を参照してください（NDC 2014で開催）
• SCOPE_EXITが最終的に複製できるのは、デストラクタからは確実に機能しないが、finallyから投げることは技術的に完全に問題がないためです。
• しかし、とにかく、人々は最終的に内側から投げることは悪い考えだと思う傾向があるように思えます。

また、デストラクタでコードを実行する責任を除いて、c'tor / d'torが概念的に何かを「取得」または「作成」する必要があるとは思いません。これが最終的に行うことでもあります。コードを実行します。

そして、finallyブロック内のコードは確かに例外をスローする可能性がありますが、明示的なものと暗黙的なものとでは概念的に異なると言うのに十分な違いではありません。

（さらに、「良い」コードが最終的にスローされるべきだとはまったく確信していません。おそらくそれは、それ自体に対する別の全体的な質問でしょう。）