0

これが可能かどうかはわかりません。

X から派生したすべてのクラスがローカル スタックまたはメンバー変数としてインスタンス化されないようにする必要があります。私はすべてのデストラクタを保護しました。これは、スコープ外に関する限り、うまくいきました。ただし、それらが単独でインスタンス化されるのを防ぐ必要もあります。Y が Z 型のメンバー変数を持っているか、そのメソッドで Z 型のローカル変数をインスタンス化する場合、これはそれをカットしません。

これで、階層ツリーのすべてのリーフにプライベート デストラクタを作成できましたが、問題は、すべてを (ヒープ) 変数にすることを許可しないことです。X <- Y <- Z の場合、3 つすべてをインスタンス化する必要がありますが、X と Y はプライベート デストラクタを持つことはできません。さらに、Z のメソッドで Z 型のローカル変数を使用することを止めません。

それらのコンストラクターをプライベートにし、operator new をそれらすべてにフレンドとして追加することでうまくいくと思いますが、これは多くの追加作業になり (operator new のいくつかのバージョンを使用するため)、階層が大きくなります。

では、private-constructors-friend-new-way に頼らずに、これらのオブジェクトのスタック インスタンス化で (できれば) コンパイル時エラーまたは実行時エラーが発生する方法はありますか?

<編集> 問題は、このプロジェクトの以前のプログラマーが大量のコードを書き、この階層内のすべてのクラスが非常に複雑なデストラクタを持っていることです。また、作成者はこれらのデストラクタで仮想メソッドを無差別に呼び出したため、(彼らにとって) 説明のつかないクラッシュやメモリの破損が多数発生しました。すべてのデストラクタをobj->Release()パターンに変換し、私が持っている最上位のリリースでdelete this. 明らかに、これはスタック オブジェクトに対しては機能しないため、独自のクラッシュをいくつか導入しました。また、私はちょっと時間が足りないので、この特定のクラッシュメソッドの実行/クラッシュの待機/修正は非常に遅いです </edit>

4

1 に答える 1

0

アイテム27の彼の著書「MoreEffectiveC++」で、Scott Meyers(ちなみに、C ++に関する私のお気に入りの著者)は、一般的な意味で、ポータブルまたはセミポータブルC ++の範囲内で、オブジェクトがオブジェクトであるかどうかを明確に区別できない理由を説明しています。スタック、ヒープに割り当てられるか、静的に割り当てられます。また、オブジェクトをスタックまたはヒープにのみ割り当てることができるようにするためのさまざまなオプションについても説明します。それらの1つは多かれ少なかれ実行可能であり、もう1つは真にポ​​ータブルで確実な作業方法を備えていません。どっちがどっちか忘れちゃう。(本は仕事中です、私は家にいます。)

于 2012-12-05T09:46:17.297 に答える