この記事のポイント

• アラインメント要件をレビューアーが読み解く技術を整理
• 構造体設計とポータビリティ観点のレビュー指摘を整理
• アラインメント設計の意図明示を促すレビュー技術を解説

そもそもアラインメントとは

C++におけるアラインメント（整列）は、
メモリ上の配置アドレスを型の境界に揃える制約です。

struct Example {
    char c;
    int i;
};

上記のような構造体でも、実際の配置は以下のようにパディングされます。

レビューアーは
「どこまでアラインメントが意図されて設計されているか？」
を読み取る役割を持ちます。

なぜこれをレビューするのか

アラインメント設計は放置されると以下の実害を生じます。

• 誤ったポーティングでクラッシュ（ARM系など）
• パフォーマンス劣化（クロスキャッシュライン）
• ABI非互換問題（FFIやバイナリ互換）

レビュー段階で
「アラインメントが偶然なのか、設計意図か」
を確認することが重要です。

レビューアー視点

• メンバ順序が適切に整理されているか
• パディング量が設計で意図されているか
• alignas指定が必要な設計意図か確認
• API契約にバイナリ互換性要求が存在するか
• 可搬性を考慮したアラインメント定義になっているか

開発者視点

• メンバ順序整理で暗黙パディングを抑制
• alignas指定は理由あるときのみ使用
• ABI契約用のバイナリ構造体は特別扱い
• ポータビリティ重視で自然整列を優先

良い実装例

想定：APIリクエストログのアラインメント設計

#include <string>

struct ApiRequestLog {
    int requestId;        // 4byte
    int responseCode;     // 4byte
    time_t requestedAt;   // 8byte
    std::string endpoint; // 8byte内部管理
    std::string clientIp; // 8byte内部管理
};

良いポイント

• メンバ順序を意識して自然アラインメント優先
• パディング量最小化
• ABI依存せず自然配置
• alignas不要（理由がない）

レビュー観点

• メンバ順序整理によりアラインメント意図が読み取れるか
• alignas指定は設計理由が明示されているか
• ABI互換性を要求される箇所のみ特殊扱いされているか
• 暗黙パディング発生箇所が読める設計になっているか
• FFI連携設計時はポータビリティ対策が組み込まれているか

良くない実装例: ケース1（メンバ順序配慮不足）

struct ApiRequestLog {
    char flag;
    int requestId;
    time_t requestedAt;
};
@Reviewer
メンバ順序で不要なパディングが挿入されています。サイズ縮小のため、int→time_t→char順に並び替えてください。

問題点

• 3byte分のパディングが自動挿入
• 不要なアラインメント拡大

改善例

struct ApiRequestLog {
    int requestId;
    time_t requestedAt;
    char flag;
};

良くない実装例: ケース2（理由のないalignas使用）

struct alignas(32) ApiRequestLog {
    int requestId;
    int responseCode;
    time_t requestedAt;
};
@Reviewer
alignas指定は必要要件が明示される場合のみ使用してください。不要に指定すると可搬性を損ねます。

改善例

struct ApiRequestLog {
    int requestId;
    int responseCode;
    time_t requestedAt;
};

良くない実装例: ケース3（ABI契約未考慮の構造体）

struct ApiBinaryPacket {
    char header;
    int payloadSize;
    uint64_t timestamp;
};
@Reviewer
バイナリ互換が必要なら#pragma pack使用または静的アラインメント保証が必要です。ABI契約内容に合わせた整列設計を明示してください。

改善例

#pragma pack(push, 1)
struct ApiBinaryPacket {
    char header;
    int payloadSize;
    uint64_t timestamp;
};
#pragma pack(pop)

観点チェックリスト

• メンバ順序最適化により暗黙パディング抑制できているか
• alignas指定理由が設計に明示されているか
• ABI契約用構造体は整列設計が保証されているか
• バイナリ互換の可搬性が配慮されているか
• パフォーマンス目的の整列が妥当な理由か確認されているか
• 例外安全性・RAII構造と衝突していないか

まとめ

アラインメントレビューは
「メモリ配置が意図として読めるレビュー」です。

レビューアーは常に

• アラインメントが自然整列で済んでいるか？
• alignas・pack指定は必要条件が存在するか？
• ポータビリティを破壊していないか？

を読み解き、安全設計＋互換性保証の両立へ誘導することが役割です。