問題タブ [object-lifetime]

コードの他の部分もフォームに属するプロパティを介して参照を取得するインターフェイスオブジェクトの背後にある機能を提供するDelphiフォームがあります。子オブジェクトにインターフェース機能を委任することはできません。その機能の多くがフォーム上のコントロール/コンポーネントによって提供されているためです。TFormクラスはTinterfacedObjectから継承せず、Delphiは多重継承をサポートしていないため、TAggregatedObjectまたはTContainedObjectを使用して、フォームに渡されるインターフェイスオブジェクトの存続期間をリンクできません。そのため、TInterfacedObjectを継承チェーンに混在させることはできません。 。この状況は、他のコードがフォームによって渡されたインターフェイス参照の1つを保持しているときにフォームが破棄された場合に、アクセス違反につながる可能性があります。誰かがこの問題の良い解決策を考えることができますか？

私は C# から来て、私の実践のいくつかを C++ に翻訳しようとしています。生のポインターを使用して、コード全体のさまざまな場所で依存性注入を使用しました。次に、生のポインターを std::shared_ptr のものに置き換えることにしました。そのプロセスの一環として、自動変数を動的に割り当てるのではなく、スタックに割り当てられた自動変数を使用することを検討することが提案されました (この質問を参照してください。その質問は unique_ptr のコンテキストにあったため、異なる可能性があります)。

以下の例は、自動変数の使用を示していると思います。

上記の例で、customAppservice と myclass が範囲外になった場合、どちらが最初に破棄されるかをどうやって知ることができますか? customAppService が最初に破棄された場合、MyClass デストラクタは失敗します。これは、このシナリオで代わりに shared_ptr を使用する正当な理由ですか、それともこれを回避するクリーンな方法はありますか?

アップデート

ApplicationService は、コードが使用するサードパーティ ライブラリと対話するために必要なグローバル関数のラッパーであるクラスです。単体テストと独立した関数のスタブ/モックをサポートする標準的な方法であると信じているため、このクラスがあります。このクラスは、対応するグローバル関数への呼び出しを委任するだけです。呼び出し appService_.Destroy(something); MyClass の特定のインスタンスごとに使用されるオブジェクトを実際に破棄していますが、Application クラス自体とは何の関係もありません。

この回答に続いて、ラムダの有効期間のルールと、自動変換によって作成される関数ポインターの有効期間との関係について疑問に思っています。ラムダの寿命についていくつかの質問があります (例: hereおよびhere )。その場合、答えは「完全なファンクター オブジェクトを自分で記述したのとまったく同じように動作する」ですが、関数ポインターへの変換についてはどちらも対処していません。特別なケース。

私の懸念を説明するこの小さな実用的な例をまとめました。

これは両方のケースで明確に定義されていますか? それともretFun1()？問題は、「関数ポインターが指す関数は、ファンクター オブジェクト自体を呼び出す必要があるか、それとも別の関数で本体を再実装する必要があるか?」です。どちらも理にかなっていますが、関数ポインターへの変換には特にキャプチャーのないラムダが必要であるという事実は、実際には後者である可能性があることを示唆しています。

別の言い方をすれば、コンパイラがそのようなラムダを実装したいと思うかもしれない少なくとも 2 つの賢明な方法を見ることができます。可能な合法的な実装の 1 つは、コンパイラが次のようなコードを合成することです。

その場合、 のバリアントstaticと非staticバリアントの両方でretFun問題ありません。ただし、コンパイラが次のようなラムダを実装することも合法である場合:

その後retFun2()は未定義の動作です。

As I make the transition from C# to C++ I get a lot of recommendations to use value semantics where possible. It's pretty much guaranteed that if I post a question with a pointer anywhere someone will come along and suggest that it should be a value instead. I'm starting to see the light and I have found a lot of places in my code where I could replace dynamic allocation and pointers with stack allocated variables (and usually references). So I think I have a grasp on using stack allocated objects and passing them to other functions as references when the object lifetime is longer in the caller than the callee.

However I have a question about passing objects by value when the callee will take ownership. Take the following example:

Typically from a flexibility and unit testing perspective I'd want Animal to be an interface (abstract class in C++) so I can easily send arbitrary animals and mock it out with a mock implementation.

In a pointer implementation client code would be calling this like:

Here the client code doesn't really need the animal object. It's just constructing it temporarily to pass to the method. So in this case there aren't shared semantics. So it seems like a good case for value semantics. However, my understanding is that you can't use Animal as a parameter passed by value because it's an abstract class.

Most of my member functions that don't take primitive types take abstract class parameters. So what is the C++ method to handle this problem? (That is how do you program to interfaces in C++ with value semantics?)

これは出力されますF~が、私は期待していました~F

Most-important-const がルールではなく例外であることを示す反例として、これを作成しました。通常は次のように記述されます。

const 参照が一時オブジェクトにバインドされると、その一時オブジェクトの有効期間が参照の有効期間まで延長されます。

Foo()は一時的なものです_xが、変換演算子によって返されるへの参照はそうではなく、上記のコードは安全ではないことを説明しようとしました。

しかし、出力は、例が安全であることを証明しているようです.一時の寿命はFoo()、そのメンバーの1つへのconst参照の存在によって延長されます.

これは正しいですか？これは標準のどこに指定されていますか?

私はちょうどこの記事を読みました：ガベージコレクションについての真実

「A.3.3非表示」のセクションでは、オブジェクトがいつどのようにinvisible状態になるかについて説明します。

以下のコードでは、変数に割り当てられたオブジェクトはブロックを離れた後にfooなり、メソッドが終了するまで強く参照されたままになります（ループは永久に実行されるため、これは発生しません）。invisibletry/catchrunwhile

それはこの記事で述べられています：

ただし、JVMを効率的に実装すると、参照がスコープ外になったときに参照がゼロになる可能性は低くなります。

なぜそれは効率的ではないのですか？

私の説明の試みは次のとおりです。

このメソッドのスタックに4つの要素が含まれていて、現在は表示されていないオブジェクトが下部にあるとします。
オブジェクトを即座に収集したい場合は、3つの要素をポップして保存し、4番目の要素をポップして破棄してから、まだ有効な3つの要素をスタックにプッシュして戻す必要があります。
制御フローがメソッドを離れた後に非表示のオブジェクトを収集するrunと、VMは4つの要素すべてをポップして、それらを破棄することができます。

これは明らかだと思いますが、IIS 7.5 でホストされている WCF サービスのコンテナーの有効期間について明確な答えを見つけることができませんでした。

コンテナーがサービス コード内に存在する場合、InstanceContextMode が single に設定されていない限り、コンテナーはすべての要求で作成されますか? （私は悪い考えを知っています）

ServiceHostFactory と IInstanceProvider を使用して WCF を構成し、コンテナーを使用してすべての呼び出しでサービス オブジェクトを解決すると、InstanceContextMode はどのように機能しますか? コンテナーで使用される有効期間ポリシーに依存しませんか?

ファクトリで作成されたシングルトンで十分な場合、コンテナは呼び出しごとに再初期化されませんか?

ありがとう

現在、ASP.NET MVC でプロジェクトを作成しています。DBのみで動作するWebプロジェクトとDBプロジェクトがあります。レイヤーはこのように見え、兄弟レイヤーとのみ相互運用します。

DB プロジェクト (EF CF) - db リクエストを作成します

リポジトリ- 基礎となる db モデルの抽象化

サービス- すべてのビジネス ロジックがここで発生します。

ASP.NET MVC Web アプリケーション- フロント エンドのプレゼンテーション

それらは疎結合でなければならないので、Unity DI/IoC フレームワークを使用しています

私が達成したいのは、DbContexthttp リクエストごとに 1 つのインスタンスを作成することです。以下は、これまでに実装したロジックです。

Items現在の辞書にHttpContextがない場合、要求パイプラインDbContextで が追加されます。すべてのコントローラーはそれを継承します。私がそうしている理由は、実行中に呼び出されるすべてのリポジトリがDbContext、すべての連続した db 呼び出しに対してまったく同じオブジェクトを使用する必要があるためです。

1. オブジェクトの寿命を と結合するより良い方法はありHttpContextますか?
2. Unity (DI/IoC フレームワーク) を使用してそれを行うことは可能ですか?

delegate変数をキャプチャするのでthis._bar、暗黙的にのインスタンスを保持しますBか？のインスタンスはB、イベントハンドラーを介して参照され、？のインスタンスによってキャプチャされた変数になりますAか？

メソッド_barのローカル変数だったら違うのでしょうか？AttachToAEvent

私の場合、インスタンスのA寿命ははるかに長く、のインスタンスよりもはるかに小さいので、これBを行うことで「メモリリーク」が発生するのではないかと心配しています。

私は、C＃コンパイラ（重要な場合は4.0）の側で非常に奇妙なコード生成に遭遇したときに、オブジェクトの寿命を（合法的に）延長する可能性についての質問に答えていました。

私が見つけることができる最短の再現は次のとおりです。

1. 包含型の静的メソッドを呼び出しているときにローカルをキャプチャするラムダを作成します 。
2. 生成されたデリゲート参照を、含まれているオブジェクトのインスタンスフィールドに割り当てます。

結果：コンパイラは、理由がない場合に、ラムダを作成したオブジェクトを参照するクロージャオブジェクトを作成します-デリゲートの「内部」ターゲットは静的メソッドであり、ラムダ作成オブジェクトのインスタンスメンバーは必要ありませんデリゲートが実行されるときに触れられる（そして触れられない）。事実上、コンパイラーは、プログラマーがthis理由なくキャプチャしたように動作しています。

リリースビルド（「より単純な」C＃に逆コンパイルされた）から生成されたコードは次のようになります。

クロージャ <>4__thisオブジェクトのフィールドにオブジェクト参照が入力されているが、そこから読み取られることはないことに注意してください（理由はありません）。

では、ここで何が起こっているのでしょうか。言語仕様はそれを可能にしますか？これはコンパイラのバグ/奇妙なことですか、それともクロージャがオブジェクトを参照する正当な理由がありますか（私は明らかに欠落しています）？これは、閉鎖に満足しているプログラマー（私のような）が無意識のうちに奇妙なメモリリーク（デリゲートがイベントハンドラーとして使用された場合を想像してください）をプログラムに導入するためのレシピのように見えるので、私は不安になります。