スケジュールナースのブログ

Q. alignasで指定した構造体を無理やり無視して配置したら例外が生じますか？

結論から言うと、例外（シグナル）が発生してプログラムが強制終了する可能性は十分にあります。ただし、例外が起きるかどうかはCPUのアーキテクチャ（x86_64かARMかなど）や実行する命令、OSのビルド設定に依存します。

C++の言語仕様（規格）上は、alignas で指定されたアライメント要件を満たさないポインタへのアクセス（未整列アクセス / Misaligned Access）は未定義動作（Undefined Behavior）となります。

何が起こるのか、詳細と具体的な挙動を以下に整理しました。

💥 実際に起こる3つのパターン

未定義動作になった結果、システムでは主に次の3つのいずれかの挙動が発生します。

1. クラッシュする（例外・シグナルの発生）

一部のCPUアーキテクチャや特定の命令では、アライメントがズレたメモリにアクセスした瞬間にハードウェア例外が発生します。

発生するシグナル: Linuxなどでは SIGBUS（バスエラー）、Windowsでは EXCEPTION_DATATYPE_MISALIGNMENT が発生し、プログラムが強制終了します。
特に危険なケース: alignas(16) や alignas(32) を使って、SIMD命令（SSE, AVX, NEONなど）の最適化を期待している場合です。例えば、x86_64のAVX命令（vmovaps など）は、メモリが32バイト境界に配置されていることを前提としており、1バイトでもズレていると確実にハードウェア例外（一般保護違反）で即死します。

2. 速度が著しく低下する（低速だが動く）

近年の一般的なデスクトップ向けCPU（IntelやAMDのx86_64など）の通常の命令（SIMDではない通常の整数演算など）は、アライメントがズレていてもハードウェア側で自動的にリトライしてデータを読み込んでくれます。

ペナルティ: 例外は出ませんが、メモリキャッシュの境界をまたぐため、通常の数倍〜数十倍のアクセス時間がかかり、パフォーマンスが大幅に低下します。

3. カーネルが裏で救済する（OSによるオーバーヘッド）

一部のアーキテクチャ（古いARMやMIPS、IA-64など）では、アライメントエラーが発生した際にOS（カーネル）が割り込みをキャッチし、正しい位置から数回に分けてデータを読み直してプログラムに返す処理を「裏でコッソリ」行う機能があります。

ペナルティ: プログラムは落ちずに動きますが、OSの割り込み処理が挟まるため、速度は壊滅的に遅くなります。

💻 発生するケースの具体例

以下のように、アライメントを無視して無理やりキャストするようなコードを書くと危険です。

cpp

#include <iostream>
#include <new>

struct alignas(32) MyStruct {
    float data[8];
};

int main() {
    // 32バイトアライメントを無視して、適当にバイト配列を確保（多くの場合16や8バイト境界になる）
    char raw_buffer[sizeof(MyStruct) + 32]; 
    
    // 無理やり中途半端なアドレス（例: 奇数アドレス）を計算
    void* misaligned_ptr = reinterpret_cast<void*>(&raw_buffer[1]); 

    // 未定義動作：アライメントを満たさない場所にオブジェクトを配置
    MyStruct* obj = ::new (misaligned_ptr) MyStruct();

    // 💥 ここでアクセスした際、コンパイラが「32バイト整列されている」と信じて
    // 高速なSIMD命令（vmovaps等）を出力していると、一発でクラッシュ（SIGBUS / 強制終了）します。
    obj->data[0] = 1.0f; 

    std::cout << obj->data[0] << std::endl;
}

コードは注意してご使用ください。

💡 まとめ

コンパイラは alignas を見ると、「このポインタは絶対に指定された境界に配置されている」という大前提で最適化コード（SIMD命令など）を生成します。それを裏切ると、コンパイラの最適化ロジックが崩壊し、最悪の場合はハードウェアレベルで例外が発生して即死すると考えてください。

もし現在、特定のバッファ（シリアライズデータや通信パケットなど）をパースする処理でアライメント問題に直面している場合は、以下の情報について教えていただけますか？

対象の CPUアーキテクチャ（x86_64、ARM32/64、マイコンなど）
どのような理由でアライメントを無視して配置したいか（メモリ節約、パケットのコピーレス化など）

状況に合わせた安全な対処法（std::align の利用や、ポインタキャストを避けた std::memcpy による安全な読み込みなど）をご提案できます。

AI は不正確な情報を表示することがあるため、生成された回答を再確認するようにしてください

シリアライズで復元するときは、どうしたらよいですか？

シリアライズされたバイナリデータ（ファイルやネットワークパケット）をメモリ上に復元（デシリアライズ）する際、「ファイル上のデータの並び（アライメント未整列）」と「C++の構造体が要求するアライメント」のズレは非常によくある問題です。

これを安全かつ高速に解決するには、主に3つのアプローチがあります。

方法1：std::memcpy を使う（最も安全・推奨）

C++において、アライメントがズレている可能性がある場所から安全にデータを読み出す最も確実な方法は、std::memcpy を使ってアライメントが保証されたローカル変数（または heap 領域）にコピーすることです。

cpp

#include <cstring>
#include <vector>

struct alignas(32) MyStruct {
    float data[8];
};

// シリアライズされた生データ（アライメントがズレている可能性があるバッファ）
void deserialize(const std::vector<char>& buffer) {
    // ❌ 絶対にやってはいけない（未定義動作・クラッシュの原因）
    // const MyStruct* bad_ptr = reinterpret_cast<const MyStruct*>(&buffer[0]);

    // ⭕ 安全な方法：一度アライメントを満たしたローカル変数を用意し、中身をコピーする
    MyStruct my_object;
    
    // std::memcpy はアライメントのズレを考慮して安全にコピーしてくれます
    std::memcpy(&my_object, buffer.data(), sizeof(MyStruct));

    // 以降は安全にアクセス可能
    // my_object.data[0] ...
}

コードは注意してご使用ください。

メリット: 100%安全。コンパイラが未定義動作の最適化でコードを壊す心配がありません。
パフォーマンス: 「コピーが発生するから遅いのでは？」と思われがちですが、近年のコンパイラ（GCC, Clang, MSVCなど）は非常に賢いため、ターゲットCPUがズレたメモリアクセスを許容する場合は、std::memcpy を最適な（クラッシュしない）1命令にインライン展開してくれます。手動でポインタをこねくり回すより高確率で高速になります。

方法2：アライメントを考慮してバッファを確保する（コピーレス）

「どうしてもコピーのコストをゼロにしたい（コピーレスパース）」という場合は、シリアライズデータを読み込むバッファ（メモリ領域）全体の先頭アドレスを、あらかじめ最大の要求アライメント（例: 32バイト境界）に強制整列させておきます。

cpp

#include <memory>
#include <new>

struct alignas(32) MyStruct {
    float data[8];
};

void deserialize_zero_copy() {
    // ⭕ 32バイトアライメントされたメモリを直接確保する（C++17 std::aligned_alloc）
    // ※サイズはアライメントの倍数である必要があります
    size_t buffer_size = sizeof(MyStruct); 
    void* raw_ptr = std::aligned_alloc(32, buffer_size);

    if (!raw_ptr) return;

    // この raw_ptr に対して、ファイルやソケットから直接データを流し込む（Readする）
    //例: file.read(static_cast<char*>(raw_ptr), buffer_size);

    // 先頭が確実に32バイト整列されているため、安全にキャストして使用できる
    MyStruct* obj = reinterpret_cast<MyStruct*>(raw_ptr);

    // 使用が終わったら解放
    std::free(raw_ptr);
}

コードは注意してご使用ください。

メリット: メモリ間のコピーが一切発生しないため、超巨大なデータを扱う場合に有利。
注意点: ファイル内のデータ構造自体が、最初からアライメントを考慮してパディング（隙間）を入れて保存されている必要があります。

方法3：構造体側を「パッキング」する（アライメントを1にする）

もしデータの保存形式を自分で変更できる、あるいはファイル側にパディングが一切ない「詰め込み状態」である場合は、構造体側の alignas(32) をやめ、コンパイラ固有の機能でアライメント要件を1バイト（パッキング状態）に強制します。

cpp

// GCC / Clang の場合
struct __attribute__((packed)) PackedStruct {
    char id;
    int value; // 通常は4バイト整列だが、1バイト境界（ズレた位置）に配置される
};

// MSVC (Windows) の場合
#pragma pack(push, 1)
struct PackedStructMSVC {
    char id;
    int value;
};
#pragma pack(pop)

コードは注意してご使用ください。

メリット: reinterpret_cast でファイルを直接重ね合わせても、ハードウェア例外でクラッシュしなくなります（コンパイラが「ズレている前提」の安全なコードを出力するため）。
デメリット: alignas(32) によるSIMD高速化の恩恵は受けられなくなります。また、環境によってはアクセス速度がわずかに低下します。

🛠️ どれを選ぶべきか？の指針

迷ったら「方法1 (std::memcpy)」を選んでください。これが現代のC++における最も標準的で、バグを生まない安全な書き方です。
データが数MB〜数GBと巨大で、1高精度なリアルタイム処理（ゲームエンジン、HPC、音声映像処理など）を行っており、1ナノ秒も無駄にできない場合は「方法2（バッファ側を整列）」を検討してください。
通信プロトコルや、他言語とバイナリデータをそのままやり取りする仕様（パディングなし）の場合は「方法3（パッキング）」を選択します。

スケジュールナースのブログ

2026年11月6日金曜日

c++ alignas