この必要性は、C++の型 decay ルールとコンパイル時のデリータ選択の必要性から生じます。配列型がテンプレートに渡されると、それはポインタに decay し、スカラー（delete）と配列（delete[]）の解放を区別するための配列サイズ情報が失われます。std::unique_ptrは部分テンプレート専門化を通じてこれを解決します。主テンプレートのstd::unique_ptr<T>はスカラーのdeleteを呼び出す**std::default_delete<T>を使用し、一方でstd::unique_ptr<T[]>はdelete[]を呼び出すstd::default_delete<T[]>**をインスタンス化します。この明示的な構文により、コンパイラーはランタイム型イントロスペクションやオーバーヘッドなしに正しい破棄コードを生成することができます。
コンテキスト： 低遅延オーディオ処理エンジンは、ハードウェアドライバーAPIから受け取るPCMサンプルバッファを受け取ります。これらのバッファは、new float[buffer_size]で割り当てられたfloat*形式です。これらのバッファは、厳密なリアルタイム制約および例外安全性を維持しながら、デジタル信号処理フィルタのチェーンを通過しなければなりません。
問題： チームは、これらのCスタイルの配列にRAII安全性を提供するスマートポインタソリューションが必要でしたが、std::vectorのサイズ/容量の追跡オーバーヘッドを導入すると、SIMD操作のためのキャッシュライン整列要件を侵害してしまいました。特に、配列に割り当てられたメモリに対してスカラーのdeleteを使用すると、ヒープが破損し、オーディオパイプラインがクラッシュしてしまいます。
手動削除の生ポインタ。 このアプローチは、明示的なdelete[]呼び出しを持つ裸のfloat*ポインタを利用しました。利点：ゼロの抽象化オーバーヘッドと直接的なハードウェアAPIの互換性。欠点：例外に対して安全でなく、処理中にフィルタがスローされた場合、バッファがリークし、20の異なるフィルタステージで正しい削除ロジックを維持するのが管理不可能になりました。生産での信頼性リスクのために却下されました。
std::vector<float>コンテナ。 バッファをstd::vectorでラップすることで、メモリ管理およびサイズ追跡が自動的に行われました。利点：例外安全性と境界チェック機能の利用可能性。欠点：std::vectorは暗黙的に容量ポインタを格納し（通常は24バイトのオーバーヘッド）、オーディオハードウェアとの固定サイズDMA整列契約を破ってしまいました。また、std::vectorは可変の所有権と潜在的な再割り当てを仮定し、ドライバーの固定バッファプールと衝突します。
std::unique_ptr<float[]>専門化。 このソリューションは、**std::unique_ptr<float[]>**を使用して、**std::default_delete<float[]>を自動的にインスタンス化しました。利点：オーバーヘッドゼロ（サイズは1ポインタと等しい）、保証されたdelete[]**の呼び出し、効率的なフィルタチェインの引き渡しのためのムーブセマンティクス、コンパイル時にコピーを防ぐこと。欠点：ランタイムサイズ情報を失い、**std::make_unique<float[]>(size)**が要素を値初期化するため、PODタイプには不要な場合があります。
決定と結果。 我々は、サイズ追跡のために軽量のスパンのようなビューと組み合わせた**std::unique_ptr<float[]>を選択しました。これにより、ハードウェア整列制約に違反することなく、例外安全性が提供されました。システムは何ヶ月もメモリリークなしでオーディオストリームを処理し、明示的な配列専門化がコンパイル時に開発者が配列newでstd::unique_ptr<float>**を試みるという重大なバグを捕捉し、ランタイム前に正しい構文を強制しました。
なぜstd::unique_ptr<Base[]>**は、**new Derived[N]**からの初期化を拒否し、**std::unique_ptr<Derived>はstd::unique_ptr<Base>に変換するのですか？
配列型は単一ポインタとは異なる非共変の動作を示します。Derivedはポインタ調整を介して暗黙的にBaseに変換されますが、**Derived[]**は配列サイズが静的型に依存するため、**Base[]**に変換できません。Base[]ビューのDerived[]の要素iにアクセスすると、間違ったバイトオフセットが計算されます。したがって、std::unique_ptrの配列専門化は、異なる配列型間の変換コンストラクタを明示的に削除して不正確なメモリのアクセスを防ぎますが、スカラーバージョンは変換を許可します（安全のために仮想デストラクタが必要です）。
なぜstd::make_unique<T[]>(n)**は、**std::make_unique<T>(args...)と比較して要素を初期化し、これが適用性を制限するのですか？
配列オーバーロードstd::make_unique<T[]>(n)は、すべてのn要素に対して値初期化を行い、スカラーをゼロ初期化するか、オブジェクトをデフォルトコンストラクトします。これは、スカラー形式がTのコンストラクタへの引数を転送するのとは異なります。この区別は、個々の要素に対するコンストラクタ引数を渡すことができないため、デフォルト構築可能でない型の配列に対してstd::make_uniqueを使用することを妨げます。候補者はしばしばstd::make_unique<NonDefaultConstructible[]>(5, args)を試みますが、これはコンパイルに失敗し、手動ループまたはstd::vectorの使用を強いられます。
スカラーのstd::unique_ptr<T>がnew T[N]からのメモリを管理する際にどのような未定義の動作が発生し、なぜコンパイラは沈黙を保つのですか？
スカラーのstd::unique_ptrはstd::default_delete<T>を利用し、これはdelete（スカラーのdelete）を呼び出します。これがnew T[N]から割り当てられたメモリに適用されると、これは不整合を引き起こし、未定義の動作をもたらします—通常は最初の要素のメモリだけが解放されるか、ヒープアロケーターのメタデータが破損します。コンパイラは警告を出さないのは、テンプレートパラメータTがデカイしてしまい、new T[N]はT*を返し、std::unique_ptrの構築時に型システムが配列の区別を失うからです。この沈黙の失敗モードが、なぜ**std::unique_ptr<T[]>**が別個の型安全な代替手段として存在するのかという理由そのものです。