回答。

メモリアライメントとは、特定のバイト数に基づくアドレスにデータを配置することを指し、これはアーキテクチャやデータ型に応じています。正確なアライメントは、パフォーマンス、ハードウェアとの正しい相互作用、および一部のプロセッサ命令にとって重要です。

この問題の歴史。

初期のコンピュータでは、アライメント違反がハードウェアエラー（バスエラー）を引き起こすことがあり、プロセッサの計算能力は非倍数のデータアドレスに敏感でした。現代のアーキテクチャでも、正しいアライメントはペナルティなしで1クロックサイクルでデータにアクセスできることを保証します。

問題。

構造体がアライメントを考慮せずに配置されると、読み取り/書き込みが遅くなるか、あるいは不可能になることがあります（例えば、ARMやMIPSでのクラッシュ）。さらに、低レベルAPI、デバイス、またはネットワーク越しのデータシリアル化の動作も妨げられます。

解決策。

C++では、アライメントを制御するためにalignas（C++11）やstd::alignのキーワード、ならびに非標準のコンパイラ属性（GCC/Clangの__attribute__((aligned(N)))やMSVCの__declspec(align(N))）があります。

コード例:

struct alignas(16) MyStruct {
    int a;
    double b;
    char c;
};

#include <iostream>
#include <type_traits>

int main() {
    std::cout << alignof(MyStruct) << std::endl; // 16
    std::cout << sizeof(MyStruct) << std::endl;
}

主な特徴:

ハードウェア要件（SIMD、デバイス）に対する正しいデータ配置。
構造体のサイズとアクセス速度の最適化（パディング）。
言語標準の保証（C++11のalignas、alignof）。

トリックのある質問。

structのメンバーの宣言順が構造体のサイズやアライメントに影響しますか？

はい、メンバーの順序は、メンバー間の「パディング」を直接決定し、構造体のサイズを増加させる追加バイトを加えることができます。

struct S1 { char a; int b; }; // 通常はsizeof==8（4バイトアライメントで）
struct S2 { int b; char a; }; // 通常はsizeof==8だが、パディングが少ない場合もある

アライメントを崩さずに構造体のサイズを減らすことはできますか？

はい、大きなメンバーを前に、少ないメンバーを後に配置することで可能です。データをビット幅を考慮して効率的にアライメントすると:

struct S { double d; int i; char c; }; // バラバラよりも良い

ポインタを通じてアライメントのないアドレスで作業するとどうなりますか？

C++標準はそのような動作を未定義（undefined behavior）とし、一部のCPUはSIGBUSや類似のエラーを出す可能性があります。

よくあるエラーとアンチパターン

シリアル化/ネットワーク伝送時にアライメントを無視すること。
alignofを考慮せずに異種データを共存させること。
アライメントのない型間での強制ポインタキャストを使用すること。

実生活の例

ネガティブケース

プログラマーは、アライメントを指定せずにSIMD用の独自の構造体を実装しました。その結果、未アライメントデータでの操作を試みた際に、プログラムが一部のARMデバイスでクラッシュしました。

利点:

アライメントのないコードの相対的なシンプルさ。

欠点:

異なるアーキテクチャでの予測不可能な動作、プログラムの異常終了。

ポジティブケース

ビデオデータ（SSE/AVX）を扱うプロジェクトでは、バッファの構造体にalignasを適用し、常にSIMD命令を効果的に使用できるようにしました。