私は実際には「場合による」には同意しません。オプション 2 は使用しないでください。translationtime 定数を使用する場合は、常にオプション 1 または std::array を使用してください。あなたがリストした利点の 1 つは、動的配列は割り当てられるまでは何の重みも持たないということですが、実際には恐ろしい、大きな欠点であり、強調して指摘する必要があります。
複数の構築フェーズを持つオブジェクトを使用しないでください。決して、決して。それは、いくつかの大きな入れ墨を通して記憶にコミットされたルールであるべきです. 絶対にしないでください。
完全に死んでいないにもかかわらず、まだ完全に生きていないゾンビオブジェクトがある場合、それらの存続期間を管理する複雑さは指数関数的に増大します。すべてのメソッドが完全に生きているか、生きているふりをしているだけかをチェックする必要があります。例外の安全性には、デストラクタで特別なケースが必要です。1 つの単純な構築と自動破棄の代わりに、N 個の異なる場所 (# メソッド + dtor) でチェックする必要がある要件を追加しました。また、チェックしてもコンパイラは気にしません。また、他のエンジニアはこの要件をブロードキャストしないため、チェックせずに変数を使用して安全でない方法でコードを調整する可能性があります。そして今、これらのメソッドはすべて、オブジェクトの状態に応じて複数の動作を行うため、オブジェクトのすべてのユーザーが何を期待するかを知る必要があります。 ゾンビはあなたを台無しにします(コーディング)人生。
代わりに、プログラムに 2 つの異なる自然寿命がある場合は、2 つの異なるオブジェクトを使用してください。ただし、これはプログラムに 2 つの異なる状態があることを意味するため、ステート マシンが必要です。一方の状態にはオブジェクトが 1 つだけあり、もう一方の状態には両方のオブジェクトがあり、非同期イベントで区切られています。2 つのポイント間に非同期イベントがない場合、それらがすべて 1 つの関数スコープに収まる場合、分離は人為的であり、単一フェーズの構築を行う必要があります。
変換時間のサイズを動的割り当てに変換する唯一のケースは、サイズがスタックに対して大きすぎる場合です。次に、メモリの最適化に進みます。最適なものを確認するには、メモリとプロファイリング ツールを使用して常に評価する必要があります。オプション 2 は決して最善ではありません (これはネイキッド ポインターを使用するため、ここでも RAII と自動クリーンアップと管理が失われ、不変条件が追加され、コードがより複雑になり、他のユーザーが簡単に解読できるようになります)。ベクトル (ビットマスクで提案されている) が適切な最初の考えですが、ヒープ割り当てコストが時間内に気に入らない場合があります。その他のオプションは、アプリケーションのイメージ内の静的スペースである場合があります。ただし、これらは、メモリの制約があると判断した場合にのみ考慮する必要があり、そこから何をすべきかは、実際の測定可能なニーズによって決定する必要があります。