歴史: C++20以前、開発者はオブジェクト表現を再解釈するためにreinterpret_cast、union、またはstd::memcpyに依存していました。これらの方法は、厳密なエイリアス規則やアクティブメンバールールによる未定義動作を引き起こすか、型安全性やconstexprサポートが不足していました。委員会は、ある型のオブジェクト表現を別の型としてアクセスするための明確なメカニズムを提供するためにstd::bit_castを導入しました。
問題: std::bit_castは、未定義動作を引き起こすことなく、ソースオブジェクトのビットパターンが宛先オブジェクトに正確に保持されることを保証しなければなりません。これには、ソースタイプがバイト単位で安全にコピーできる（トリビアルコピー可能）ことと、移送中に情報が失われたりねつ造されたりしないこと（同一サイズ）が必要です。これらの制約がないと、操作がオブジェクトをスライスしたり、プライベートコピーセマンティクスをバイパスしたり、宛先型に対して無効なビットパターンを生成したりする可能性があります。
解決策: 標準は、両方の型がトリビアルコピー可能（バイト単位のコピーを許可）であり、サイズが同一であることを義務付けています。実装は、std::memcpyに相当するビット単位のコピーを行いますが、型安全性とconstexpr評価のサポートがあります。これにより、ポインタキャストの厳密なエイリアス問題とunionのアクティブメンバー制限を回避し、型パニングのためのポータブルで最適化可能なプリミティブを提供します。
struct Packet { uint32_t id; float value; }; static_assert(std::is_trivially_copyable_v<Packet>); Packet p{42, 3.14f}; auto bytes = std::bit_cast<std::array<std::byte, sizeof(Packet)>>(p); Packet restored = std::bit_cast<Packet>(bytes);
マルチプレイヤーゲームエンジンでは、物理システムがTransform構造体を生成し、位置と回転データのfloatを含みます。ネットワーク層はこれを生のバイトとしてゼロコピーオーバーヘッドで送信する必要があります。最初の実装ではreinterpret_cast<const std::byte*>(&transform)を使用してバイトシーケンスを取得しましたが、これは厳密なエイリアス規則に違反し、攻撃的なコンパイラ最適化（-fstrict-aliasing）の下でクラッシュを引き起こしました。
手動フィールド抽出: 各floatを個別にシリアライズし、バイトバッファにビットシフトします。このアプローチは定義された動作を保証し、エンディアン変換を明示的に処理しますが、複雑な構造の場合は何百行ものボイラープレートを必要とし、フィールドが変更されるとメンテナンスが重くなり、大きな配列に対するループ操作からCPUオーバーヘッドが発生します。
Union型パニング: union TransformPayload { Transform t; std::byte bytes[sizeof(Transform)]; }を定義し、transformメンバに書き込んだ後にバイトメンバにアクセスします。これはGCCやClangのコンパイラ拡張としてサポートされていますが、**C++**標準のアクティブメンバールールに違反します（一度に1つのunionメンバのみがアクティブであること）。これにより、リンク時最適化（LTO）が有効な場合に不正なバイト値が発生する未定義動作が発生します。
std::memcpy: std::memcpy(dst, &transform, sizeof(Transform))を使用してtransformをバイト配列にコピーします。これはトリビアルコピー可能な型に対しては定義が明確であり、単一のCPU命令に最適化されます。ただし、事前に確保されたストレージが必要であり、inverse操作に対するconstexprサポートがC++20以前のコンテキストでは欠けており、キャスト操作に比べてコードの意図が不明瞭になります。
std::bit_cast: auto packet = std::bit_cast<std::array<std::byte, sizeof(Transform)>>(transform);を使用して構造体を直接変換します。これにより、constexpr対応の型安全な変換が可能となり、パケット構造をコンパイルタイムで検証できます。これにはC++20のサポートが必要で、Transformがトリビアルコピー可能であることを物理システムがすでに保証しており、構文はポインタキャストの曖昧さなくビット単位の再解釈を明示的に表現します。
チームはC++20へのビルドシステムの移行後にstd::bit_castを選択しました。これにより、未定義動作が排除され、unionパニングのクリーンな構文が維持され、constexpr機能によりネットワークパケット構築が自動化テスト中にコンパイルタイムに検証されることができました。
ネットワークモジュールは、抑制ルールなしでUBSanとASanのチェックに合格しました。性能ベンチマークでは、memcpyと同じスループット（x86_64での変換あたり0.3ns）を示し、静的分析ツールはエイリアス違反をフラグ付けしなくなりました。コードは生産環境で1秒あたり100,000のトランスフォームを正常にデシリアライズします。
std::bit_castがソースと宛先の型に同一のサイズを要求する理由は何ですか？パディングバイトが型間で異なる場合はどうなりますか？
同一サイズの要求は、ビットパターン間の双射的マッピングを保証します。ビットが切り捨てられたり作成されたりすることはありません。サイズが異なる場合、キャストは不正な形式になります。パディングバイトはソースオブジェクトに存在する状態で正確に保持されます。ただし、宛先型が異なるパディング要件を持っている場合、後で宛先型を通じてそのパディングバイトを読み取ることは依然として有効ですが（それらは宛先オブジェクトの値表現の一部になります）、その値は未指定です。これは、std::bit_castがパディングをコピーできるが、パディングビットを特定の値として移植可能に解釈することはできないことを意味します。
std::bit_castは、オブジェクトの寿命とストレージの持続性に関してreinterpret_castとどのように異なりますか？
reinterpret_castは同じストレージロケーションへのエイリアスを作成し、型が無関係である場合に厳密なエイリアス規則に違反する可能性があり、新しいオブジェクトを作成しません。std::bit_castは概念的に、自動ストレージの持続性を持つ宛先型の新しいオブジェクトを作成し（または定数式で使用した場合はconstexprストレージ）、ソースからビットパターンをコピーします。エイリアスを作成せず、ソースと宛先は異なるオブジェクトです。この区別により、std::bit_castはreinterpret_castが禁止されているconstexprコンテキストで使用することができ、定数評価を逃がすポインタを経由するキャストを必要としません。
std::bit_castは、同じサイズの整数にポインタをキャストするために使用できますか？この理由で、実装依存の結果になる可能性があるのはなぜですか？
はい、sizeof(T*) == sizeof(U)であれば、std::bit_castはそれらの間で変換できます。ポインタはトリビアルにコピー可能です。ただし、結果は実装依存であり、標準はポインタ値の特定の表現を義務付けていません（例: セグメントアドレッシング、タグ付きポインタ）。ビットは正確に保持されますが、それらのビットを整数として解釈したり、ポインタに戻したりすると実装依存の値が得られます。これは、ポインタから整数、そして再びポインタへの往復変換を保証するreinterpret_castとは異なり、std::bit_castはポインタをビットの袋として扱い、コンパイラがエイリアス分析に使用する起源情報を失います。