問題タブ [destruction]

自動オブジェクト（スタック上に作成されたオブジェクト）の破棄は、スコープ外になる前に実行されることが保証されていますか？

明確にするために：

を印刷する"2"必要aがなくなったため、理論的には、コンパイラは、a必要がなくなったらすぐに最適化と破棄を試みることができます。

上記の機能を常に印刷することに頼ることはできます123か？

この記事を見ていたら、「基本クラスのデストラクタに入ると、オブジェクトは基本クラスのオブジェクトになり、仮想関数、dynamic_castsなどのC++のすべての部分がそのように処理されます」と書かれています。これは、破壊中にvptrが変更されたことを意味しますか？それはどのように起こりますか？

つまり、stf2 の Dispose() メソッドが最初に呼び出されることが保証され、次に stf1 の Dispose() メソッドが 2 番目に呼び出されることが保証されますか? (基本的に: Dispose() メソッドは、それらが属するオブジェクトの割り当てとは逆の順序で呼び出されますか?)

アプリケーションのメモリ リークに対処する試みの一環として、すべてSkinnableComponentの に対して、がデフォルトskinDestructionPolicyで に設定されていることを発見しました。"never"

これは、静的なスキン パーツを使用すると、スキンがメモリ内に永久に保持されることを意味します。
さらに、ホスト コンポーネントの partRemoved() のオーバーライドがトリガーされることはありません。したがって、partAdded() オーバーライドで追加したイベント リスナーは削除されません。これにより、ビューとスキンが事実上メモリに保持されます。

多くのビューの切り替えを行う場合、これは受け入れられません。

以下は、現在これを回避する方法の例です。

ただし、mx::internalこの動作を回避する方法を使用することは、私にはかなり奇妙に思えます。これに関するドキュメントも不足しているため、アイデアは大歓迎です。

乾杯

破壊可能な地形で 2D ゲームを作成しています。これは iOS に実装されますが、実際のコードではなく、アイデアや疑似コードを探しています。大量のデータを保存する方法を考えています。(これは、幅約 64000 ピクセル、高さ 9600 ピクセルの大きな世界になります。各ピクセルには、オブジェクトの種類を格納する方法が必要です。) 2D 配列を使用することを望んでいましたが、簡単な負荷テストで、これは実現可能ではないことが示されました。 (640x480 グリッドを使用しても 1 fps を下回りました) ここで説明されている方法も試しました: http://gmc.yoyogames.com/index.php?showtopic=315851（以前ゲームメーカーを使っていたのでこの方法を思い出しました）しかし、少し面倒そうで、オブジェクトを再結合することはほぼ不可能です。では、他にどのような方法があるのでしょうか。ワームがどのように機能したか知っている人はいますか? 画像エディタはどうですか? 各ピクセルの色をどのように保存しますか? ありがとう、YM

リストを繰り返し処理し、要素を使用してアクションを実行し、いくつかの基準に基づいて、アクティブな要素を削除したいと思います。ただし、以下の関数を使用すると、無限ループに陥ります。

それ自体を指しているのでそれは不可能ですか？結局のところ、もちろんですelt。(car list)

これは正しい評価ですか？そして、どうすればこれを効率的に解決できますか？

これを理解するのを手伝ってください... 太字を参照してください。標準 3.6.3 終了 (2) より

2 関数に、破棄された静的ストレージ期間またはスレッド ストレージ期間のブロック スコープ オブジェクトが含まれており、静的ストレージ期間またはスレッド ストレージ期間を持つオブジェクトの破棄中に関数が呼び出された場合、制御フローが通過する場合、プログラムは未定義の動作をします。以前に破棄されたブロックスコープ オブジェクトの定義。同様に、ブロック スコープ オブジェクトが破棄後に間接的に (つまり、ポインターを介して) 使用された場合の動作は未定義です。

そしたらまたどこかで…

次に、ユーザーデストラクタで...

標準では、odr-use ルールで静的に作成されたローカルの static localMan オブジェクトが破棄され、関数が再度呼び出された場合 (新しい static を作成するかどうかにかかわらず)、これは未定義であると言っていますか? 定義された動作があるように見えますが、破壊されたオブジェクトの定義を通過する場合はそうではありません。

誰でもこれについて明確な洞察を持っていますか?

ベクトル要素の破棄順序は C++ 標準では定義されていないことを知っています ( std::vector の要素の破棄順序を参照)。チェックしたすべてのコンパイラが最初から最後までこの破棄を行うことを確認しました。動的配列と静的配列は逆の順序でそれを行います。この逆の順序は C++ の世界ではよくあります。

厳密に言うと、「コンテナーメンバーは、たとえばメンバー関数の挿入および消去を使用して、任意の順序で構築および破棄できる」ことを知っており、「これらの変更について何らかのログを保持するコンテナー」には投票しません。現在のベクトル デストラクタの実装を要素の前方破壊から後方破壊に変更することに投票するだけです。そして、このルールを C++ 標準に追加するかもしれません。

で、その理由は？配列からベクトルへの変更は、この方法でより安全になります。

実際の例: ミューテックスのロックとロック解除の順序が非常に重要であることは誰もが知っています。ロック解除を確実にするために、ScopeGuard パターンが使用されます。それから破壊順序が重要です。この例を考えてみましょう。そこで-配列からベクトルに切り替えるとデッドロックが発生します-それらの破棄順序が異なるためです:

OUTPUT - f1() から f2() への破棄順序の変更を確認します