データ型のアラインメントとは何か，なぜ必要なのか？

以前このサイトとブログに，何度かアラインメントに関する記事を書きました (サイト内関連ページ参照)．そのせいか「アラインメント」で検索して来てくれる人が多いので，過去の記事に加筆修正してこのページを新たに作成しました．

加筆した点は次のとおりです．

アラインメントとメモリアクセス回数の関係をわかりやすくするため， (ほんの少し) 図を導入しました．「データがアラインされていないとメモリアクセス回数が増える」と言葉で説明しているサイトは多いのですが，図で示しているところはまだ見たことありません．
アラインされていないアドレスにデータを書き込む場合，読み出しの場合以上にメモリアクセス回数がかかる可能性があることを追記しました．
以前は「複合データ型 (配列，構造体，共用体) のアラインメント」はほとんど自明のことだと思っていたので軽く流していましたが，意外なことにこれを解説しているサイトが全く見つからないので詳しく解説しました．
Ｃ言語等の解説サイトでは，構造体のアラインメントについて解説しているところも多いのですが，その場合問題にしているのはメンバのアラインメントであって，構造体全体のアラインメントについては何も触れていません．そのうえメンバは (暗黙のうちに) 基本データ型という前提になっています．

つまり複合データ型それ自体のアラインメントはどうなるのか，ということに触れているサイトはまだ見たことがありません．
- 追記１：あるプロセッサの仕様書で見つけましたが，これを読んだ人は一般性のあるアラインメント規則ではなく，このプロセッサ固有の規則だと思うかもしれません (外部へのリンクの「SPU Application Binary Interface 仕様書」を参照)．)
- 追記２：久しぶりに検索してみると，Microsoft のページに説明があった痕跡を見つけましたが，今そのページはなくなっています．
  - 2007/09/30(日) 追記
    別の (それとも復活した？) Microsoft のページを見つけました．
    Visual C++：集約と共用体
    このページで「埋め込み」と言っているのはパディングのことです． (原文)
しかし上の追記に挙げたのサイトも，「なぜ複合データ型のアラインメント規則がそうなっているのか」ということは説明していません．

たぶんこのページは，日本中で最も (もしかしたら唯一の？) 詳しくアラインメントを解説したページだと思います．
(2007/01/14(日) 現在)

このページの主な更新は Blog でお知らせします．

CPU に関する基礎知識
アラインメントとは何か？
アラインされていないデータへのアクセス
1. アラインメントに寛容な CPU の場合 (alignment-tolerant processors)
2. アラインメントに厳格な CPU の場合 (alignment-strict processors)
アラインメントの基礎知識のまとめ
複合データ型 (配列，構造体，共用体) のアラインメント
Ｃ言語におけるアラインメント
CPU回路の単純化とアラインメントの関係
補足
1. 共用体の全メンバのオフセットが０である理由
参考図書
サイト内関連ページ
外部へのリンク
更新履歴

以前某所で malloc() のアラインメントについて書いたとき，「それはＣ言語の仕様なのか？」と訊かれたことがある．また「Ｃ言語アラインメント」などで検索してここに来る人も多い．アラインメントを C/C++ の問題だと思っている人が多いようだが，特定のプログラミング言語に起因する問題ではない． アラインメントは機能ではなく制約なので，わざわざそんなものを好きこのんで言語仕様に入れるメリットは何もない．

アラインメントは CPU のハードウェアに起因する問題であり，データのメモリアドレスに関する制約である． C/C++ (そしてアセンブラ) でそれが問題となる理由は， データのメモリアドレスがプログラマに見える (操作できる) 言語だからである．C/C++ のアラインメントに関する仕様は， CPU の制約を「代弁」しているにすぎない．

CPU が扱うデータ型は，基本的には整数型 (と浮動小数型) だけである．文字列は文字コード (整数型) の配列として表現される． 32ビット CPU では普通，扱える整数型のサイズは１，２，または４バイトである．これらはＣ言語ではそれぞれ，(signed または unsigned) char，short，int (または long) 型と呼ばれる．浮動小数型には４バイト長の単精度型 (Ｃ言語の float 型) と，８バイト長の倍精度型 (Ｃ言語の double 型) がある． (x86 ファミリーの中には，８バイト整数，16バイト整数， 10バイト拡張倍精度浮動小数を扱えるものもあるが，ここでは割愛する．)

最近のほとんどの CPU は，メモリ上のデータを１バイト単位で読み書きできる (バイトマシン)^注1．つまりメモリは，巨大なバイト配列と考えることができる．１バイト整数をメモリに格納する場合，どれでもいいから１つの配列要素を選び，そこに格納すればよい．その配列要素の番号がメモリのバイトアドレスとなる． (Ｃ言語の配列と同じく，要素番号 (バイトアドレス) は０から始まる．)

２バイト以上の整数型や浮動小数型を格納するには複数の配列要素が必要なので，例えば４バイト整数なら４つの連続する配列要素に格納する．この場合，最初の配列要素の番号が４バイト整数のバイトアドレスとなる．注意すべき点は，１バイトデータの場合とは異なり， 複数バイトデータのバイトアドレスは好きなように決められるわけではないということである．次にこの点について説明する．

2008/04/06(日) 追記
注1：このページの内容は，あくまでも CPU がバイトマシンであることが前提．ワードマシンの場合，そもそも「バイトアドレス」が存在しない機種もある．また Cray (１ワード＝８バイトのワードマシン) の場合， short 型の有効ビット数は32ビットだが，１ワードを占有してしまうらしい (リンク先ちゃんと読んでないけど)．この変数のアドレスはワードの先頭なのか，それとも有効な４バイトの先頭なのか？

このページの AOF32L(l) というマクロは，変数 l のアドレスを返すが，Cray の場合だけはそれより４バイト後ろのアドレスを返すらしい)．ということは，&l がワードの先頭で AOF32L(l) が有効な４バイトの先頭なのか？

Cray では，構造体の先頭メンバや共用体のメンバが short 型の場合，そのオフセットは４になるのかもしれない．

CPU とメモリの間は，データをやりとりするための電線の束で結ばれている．これをデータバスという．32ビット CPU では普通，この電線は32本あり (32ビット・データバス，下図)，CPU はメモリ上のデータを一度に32ビット (＝４バイト) 読み書きすることができる^注2．このため，メモリの最初の４バイト (アドレス０～３)，次の４バイト (アドレス４～７)，更に次の４バイト (アドレス８～11) … は，それぞれ一度で読み書きできる．普通，このような４バイトをワード (word：語) と呼ぶ．
(注意：x86 など 8/16 ビットから進化してきた CPU シリーズでは，16ビット版との互換性のため２バイトをワード，４バイトをダブルワードなどと呼ぶものが多い．逆に最初から32ビットとして登場した CPU シリーズでは， 32ビットをワード，16ビットをハーフワードと呼ぶものもある．)

したがって４バイト整数または４バイト浮動小数をメモリに格納する場合，先頭アドレスが４の倍数になるようにすれば上図の１ワードに収まるため，１回のメモリアクセスで読み書きできる．このようにデータの先頭アドレスを４の倍数にすることを，「４バイト境界にアライン (align：整列，位置合わせ) する」という．

注2：現実には，Ｎビット CPU のデータバス幅がＮビットであるとは限らない．x86 を例に取ると，32ビット CPU とは言いながら Pentium 以降は64ビット・データバスである．古くは16ビット CPU 8086 (元祖 x86) の８ビット・データバス版 8088 (初期 IBM PC に採用) というのもあった．

■参考

宜しければTTLでコンピュータを作りませんか？
TTL で CPU を自作しようとしている人のサイト．
- RETROF-8のバス幅の決定
  - 「nビットマシン」のnとは何なのか？
- DIODE.MATRIX.JP (旧サイト)

では，４バイトデータが４バイト境界にアラインされていない (４バイト境界をまたぐ，ともいう) 場合はどうなるのか？
この場合，４バイトデータＸは下図の例のように複数ワードにまたがっている． (Ｙ，Ｚは別のデータ)

このようなＸを読み書きするように命令された CPU はどうするだろうか？「２回に分けて読み書きする」と思うだろう．x86 は実際そのように動作する (ただし後述する場合を除く)．当然読み出しにはメモリアクセス１回分余計に時間がかかる． 最近の (キャッシュを持つ) CPU にとって，メモリアクセスは非常に時間のかかる処理である． 例えばメモリ上のデータを読み書きする命令は，それがキャッシュに入っていない場合，最も速い命令 (整数型の加減算やビット演算など) に比べて約100倍以上の時間がかかる．

参考：メモリのアクセス時間とローカルメモリ (コンピュータアーキテクチャの話 135，安藤壽茂，マイナビニュース)

ここまでは、メモリは1サイクルか2サイクルでアクセスができるという想定でパイプラインを考えてきたが、この想定がある程度成り立っていたのは30年以上も昔のことである。それ以降の30年で、プロセサのクロックは1000倍程度速くなったが、メモリのアクセスタイムは10倍程度しか向上しておらず、結果として、現在のマイクロプロセサがDRAMで構成されたメモリをアクセスするには、100サイクル以上を必要とするようになってきている。

メモリのロード、ストアを行う命令の出現頻度は、典型的なプログラムでは30%程度である。
(中略)
実行ユニットは、毎サイクル1命令を実行する能力があるが、メモリアクセスに45倍もの時間がかかり、1秒間に実行できる命令数はクロック周波数の1/46に低下してしまう。

さらに，アラインされていないデータがワード境界どころかキャッシュライン境界をもまたいでいた場合，もう一つのキャッシュライン (普通は32～256バイトらしい) も読むはめになってしまう！

書き込みの場合はもっとメモリアクセス回数が増える場合もある． 仮に CPU が図２の２ワードに対して単純にＸを書き込んだらどうなるだろうか？ＹとＺが巻き添えを食らって (無効な値に) 書き替えられてしまう．これを防ぐには，書き込み前に図２の２ワードを読み出しておかなければならない．つまり合計４回のメモリアクセスが必要になる．

ただし CPU がワードに書き込みを行う際，ワード内のどのバイトに書き込むかを選択できる回路がついていれば，そのような問題は発生しない．この場合のメモリアクセス回数は読み出しの場合と同じである．

x86 以外の多くの CPU (特に RISC) は上記のようには動作せず，エラーとして処理する．つまり「不正アラインメント例外^注3」を発生させる．このとき動いている OS が UNIX 系ならば，SIGBUS というシグナルが発生してコアダンプするというオチがつく ( ~~HP-UX での実例~~ )．他の OS でも同様だろう．

なぜエラー扱いするのかは CPU の設計者に聞いてみないとわからないが，まず間違いなく CPU の回路を単純にするためだろう．ワード境界をまたぐデータを２回に分けてアクセスするとなると，それだけ制御回路が複雑になる．特に RISC はそもそも次のような設計思想で生まれたものである．

命令の種類を減らして制御回路を単純化し，命令の解読および実行に要する時間を減らす．
(命令実行速度に比べて) 非常に遅いメモリアクセスをできるだけ避けるため，レジスタやキャッシュを増やす．そのために，制御回路を単純化して空いたチップ面積を利用する．

だから１つの基本データ型を２回に分けてアクセスするなどということは， RISC にとっては反革命思想・アラインメント違反罪であり，UNIX 共栄圏では SIGBUS の刑に処せられる．(笑)

(そのうち暇ができれば，アラインメントと CPU 回路の単純化の関係について追記するつもり．)

参考：コンピュータアーキテクチャの話 (安藤壽茂，マイナビニュース)

ARM も RISC なので不正アラインメント例外を発生するが， ARM Linux カーネルは例外ハンドラで x86 と同様の「アラインされていないデータのアクセス」を実現しているらしい．ただしこれは x86 に比べて非常に遅いはず．

注3： 呼び方は CPU によって異なる．ここでいう「例外」は C++ や Java 等のプログラミング言語でいう例外 (try ～ catch で捕捉できるアレ) ではなく， CPU のハードウェアが発生させる割込みの一種である．
(Visual C/C++ では，__try ～ __except でハードウェア例外を捕捉できる．コンパイルオプション /EHa を指定すれば，C++ の try ～ catch でも捕捉可能．)

2007/10/25(木) 追記
CPU によっては，アラインメント例外を発生させる代わりに， アドレスの下位ビットを強制的に０と見なして処理するものもある (↓実例)．

Renesas H8/300 のメモリ・アライメント (思考の遷移図II，魚拓)
H8/300 でわざと不整列アドレスに書き込む実験．アドレスの下位１ビットが CPU に無視され，強制的にワード (２バイト) 境界に変更されている．

2009/05/30(土) 追記
参考：ハードウェアを意識したプログラミングの基礎（後編）
x86，ARM，PowerPC，MicroBlaze でアラインされていないデータにアクセスしてみる実験．
ARM v6 以降は寛容になったらしい．

アンアラインド・データ・アクセス (ARM初心者向け連載講座 APS ACADEMY：Cortex-M入門編第8回)
ハードウェアを意識したプログラミングの基礎（後編）

2010/07/03(土) 追記

逆に x86 がアラインメントに寛容な理由は，最初からそういう仕様で設計されたわけではなく，8bit CPU 時代 (1974年の i8080) からの命令互換性を連綿と維持するためそうせざるを得なかったからにすぎない．
x86 は (アーキテクチャに関してはボロクソに言われながらも) 互換性の維持によって現在の地位を築くことができたのである．
(i8080 → i8086 はアセンブラソースレベル互換，i8086 以後はバイナリ互換．)

■参考

CPU関連の技術戦略 (1) CPUアーキテクチャの歴史的継承性、および、CPUの互換性問題 (明治大学経営学部佐野正博)
(文面を少し修正して引用．)
8080や8085は8ビットCPUとしてよく売れたため、新しい16ビットCPU 8086の開発に当たって、インテルは8ビットCPU用に書かれたソフトウエア資産の継承に配慮した。
(中略)
8086は８ビットCPUとの連続性を重視した結果として、そのアーキテクチャが「汚い」とか「洗練されていない」とか言われることがある。これに対して、Motorola社の68000は、８ビットCPUとの連続性を考えずに設計されたこともあり、そのアーキテクチャは「美しい」と言われている。
(中略)
しかしそれにも関わらず、販売量という点ではMotorola社はインテル社に比べてまったく及ばなかった。
(中略)
6809という6800系の８ビットCPUの開発においても同様であった。6809は「究極の８ビット・マイクロプロセッサ」と一部で呼ばれるほど優れたアーキテクチャを持っていたが、それ以前の6800系８ビットCPUと互換性を持っておらず、それらのCPUで動作していたプログラムが動作しなかった。Motolora社は、インテル社と異なり、それ以前のソフトウェア資産を重視しなかったのである。
コンピュータアーキテクチャの話 117 データタイプとアライメント(1) (安藤壽茂，マイナビニュース)
過去の製品からの連続性(上位互換)を維持するためには止むを得ないのであるが、この辺りがx86アーキテクチャの汚いところである。このため、 Intelのアーキテクトがこれを清算したいと考え、HPと協力してItaniumのIA-64アーキテクチャを開発したのは無理からぬところであると筆者は思うのであるが、その結果はご存知の通りである。これはアーキテクチャが技術だけでは決まらないという好例であろう。

2013/01/02(水) 追記

x86 でも，次の場合は不正アラインメント例外を発生する．

SSE 命令の多くは，使用するデータに16バイト・アラインメント厳守を要求する．これに違反した場合は一般保護例外 (#GP) が発生する．
OS の仕様によっては，ユーザプログラム (特権レベル３) が (SSE 命令以外の一般の) アラインメント違反をした時に，アラインメント・チェック割込み (#AC) を発生させることも可能． (ただしそういう仕様の OS があるかどうかは知らない．)

Visual C/C++ では，SSE のためのデータ型 (__m128 など) をサポートしているが， 32bit Windows 用の malloc，new，Win32 アロケータ等は8バイト・アラインメントしか保証していないので，これらを用いて SSE 用のデータ型を含む構造体などを確保すると， アラインメント違反 (一般保護例外 #GP) が発生する場合がある． DirectXMath / XNA Math / D3DX 等，SSE 対応のライブラリを使用する場合は _aligned_malloc() 等を使用する必要がある．

align (Visual C++ Language Reference)

To create an array whose base is properly aligned, use _aligned_malloc, or write your own allocator. Note that normal allocators, such as malloc, C++ operator new, and the Win32 allocators return memory that will most likely not be sufficiently aligned for __declspec(align(#)) structures or arrays of structures.

Windows 7 (SP1) で確認したところ，どうやら DispatchMessage() がこっそり catch して握りつぶしているらしく，例外が発生してもエラーダイアログが出ないままメッセージループが継続するので気づかない．

何バイト境界にアラインすればよいか (これをアラインメント^注4 (alignment) という) は，CPU とデータ型によって異なるが，一般には２の冪乗 (1，2，4，8，16，…) になる．基本的なデータ型のアラインメントは，その型のサイズ (バイト数) に一致することが多い．つまり１バイト整数のアラインメントは１バイト，２バイト整数のアラインメントは２バイト，４バイト整数／単精度浮動小数のアラインメントは４バイト，８バイト倍精度浮動小数のアラインメントは８バイトである．

ただし例外もある．例えばデータバス幅より大きい基本データ型をサポートする CPU では，データバス幅がアラインメントの上限になる場合もある (最初に書いたメモリアクセス回数の話からすれば当然)．例えば16ビット CPU H8/300 シリーズは４バイト整数型をサポートするが，そのアラインメントは２バイトである． (H8 の他のシリーズは使ったことがないので未確認．)

●まとめ

メモリ上のデータのアドレスは，Ｎの倍数でなければならない．このＮをアラインメントという．Ｎは CPU とデータ型によって異なる．
アラインメントは２の冪乗 (1，2，4，8，16，…) である．
アラインメントに厳格な CPU (主に RISC) では，アラインメントを守ることは必須．さもなくばエラーになるか，勝手にアドレスを変更して実行されるなど，期待と異なる動作をする．
アラインメントに寛容な CPU (x86 など) では，アラインメントを守らなくても正常に動作するが，そのデータのメモリアクセスが遅くなる．特にキャッシュライン境界をまたいだときは最悪．
基本的なデータ型 (整数型，浮動小数型) のアラインメントは，そのサイズに一致することが多い．ただし例外もあるので，実際の値は必ず言語処理系または CPU のマニュアルで確認すること．
たまに「(CPU名) (データ型名) アラインメント」等で検索してくる人がいるけど， 最初に見るべきなのはコンパイラか CPU のマニュアル． そんな検索ワードじゃ無関係なページが山盛り出てくるうえ，自分の環境と違うものを間違えて見つけてしまうかもしれない．手抜きをするつもりが時間の浪費になってしまう．最初からマニュアルを見る方が早くて確実．
最もアラインメントの厳しいデータ型では，アラインメントは CPU のデータバス幅と同じかそれ以上になるはずである．例えば32ビット・データバスを持つ CPU では４バイト以上である．

●注意

プロセッサによっては，サイズが２の冪乗でない基本データ型 (24ビット整数や48ビット整数，80ビット浮動小数など) を持つものもある．それらのアラインメントについては個別に確認する必要がある．そのようなデータ型をＣ言語で扱う場合には注意が必要である． (後述の「sizeof とアラインメントの関係」を参照．)

注4： アライメント，境界整列，境界調整[数]などと呼ぶ人もいる．

修正中 (前提条件追記)

ここでは説明の都合上Ｃ言語の用語や構文を使うが，特定の言語 (特に C/C++) の複合型の仕様についての話ではなく，メモリ上の物理的なデータ配置に関する CPU の制約の話である．したがって言語仕様よりも強制力が強い． (言語の規格に従わない「なんちゃって言語」でも動作するプログラムは書けるが，アラインメント制約を守らなければ動作しなかったり，速度低下を招いたりする．)
ここでいう「構造体」，「共用体」，「配列」の定義 (たぶんＣの規格よりも厳しい定義)．

不要なパディングを入れない (特に先頭部分)．
⇒ 構造体の最初のメンバ，配列の先頭要素，共用体の全メンバのオフセットは必ず０．
構造体は指定された順序でメンバが並ぶ．
「正味のサイズ」の定義 (配列と共用体の場合についても追記すべき)．

C++ の class/struct については，隠れたメンバ変数 (仮想関数テーブルへのポインタ) を持つ場合があったり，オフセット計算の基準位置が状況によって変わったり，ソースコード上の見かけから想像されるのとは異なるデータ構造 (仮想基底クラス) があったりするので，ここでは全く対象外．言語仕様書やソースコードだけをいくら眺めててもダメで，処理系の ABI を理解しなければ確かなことはわからない．
参考：C++ ABI Summary

ある複合データ型全体のアラインメントを求めるには，次のように考えてみるとわかりやすいだろう．

複合データが，ある適切な (つまりアラインされた) アドレスに配置されている．このデータのアドレスを少し移動させたい場合，何バイト単位で移動させることができるか？

複合データ型の変数 D に含まれる各要素データを D_i，そのアラインメントを A_i とする (i＝1，2，…，n)． D_i は A_i バイト単位でしか移動できないので， D もまた A_i バイト単位でしか移動できない．これをすべての D_i について満たすためには， D は A₁，A₂，…，A_n の最小公倍数 LCM(A₁，A₂，…，A_n) バイト単位でしか移動できない．したがって D のアラインメントは LCM(A₁，A₂，…，A_n) である．アラインメントは２の冪乗でなければならないから，それらの最小公倍数は最大値に等しい．したがって D のアラインメントは Max(A₁，A₂，…，A_n) である．

つまり (バイトマシンでは) 複合データ型のアラインメントは，それに含まれる要素のアラインメントの中で最も大きい (厳しい) ものに等しい． 特に配列の場合はすべての要素が同じ型なので， 配列のアラインメントは要素のアラインメントに等しい．

複合データ D のバイトアドレスを Addr(D) と書くことにする． D の要素 D_i の，D の先頭からのバイトオフセットを Offset(D_i) とすると，次式が成立する．

Addr(D_i) ＝ Addr(D) ＋ Offset(D_i)

D が構造体 (型名を D_t とする) の場合，上の式をＣ言語の構文で書けば次のようになる．


assert((char*)&D_i == (char*)&D ＋ offsetof(D_t, D_i));


 struct D_t
┏━━━┓←┬─ &D (== &D0)
┃D0    ┃  │
┠───┨  │
┃D1    ┃  │offsetof(D_t, Di) … Ai の倍数でなければならない．
┠───┨  │
：      ：  │
：      ：  ↓
┠───┨←┴─ &Di
┃Di    ┃
┠───┨
：      ：
：      ：
┠───┨
┃D(n-1)┃
┗━━━┛

D_i のアラインメントを A_i とすると， Addr(D_i) は A_i の倍数である (アラインメントの定義)．また「複合データ型全体のアラインメント」に書いたことから，Addr(D) も A_i の倍数である．したがって Offset(D_i) もまた A_i の倍数でなければならない．つまり複合データ型の要素のオフセットは，その要素のアラインメントの倍数でなければならない．

「構造体メンバのオフセットは，そのメンバのアラインメントの倍数に切り上げられる (パディングが挿入される)」ということは，Ｃ言語を解説している本やサイトでよく見かけるが，その理由は上記のとおりである．これをちゃんと説明しているサイトはほとんどない．まして，複合データ型のアラインメントを解説しているサイトは全く見たことがない (本はどうだか知らないが)．

なお，共用体の場合はメンバのオフセットは常に０なので，このことを考慮する必要はない．

D が配列の場合，最初の要素はオフセット０なので何の問題もない．要素のサイズがアラインメントの倍数の場合には，次の要素は前の要素のすぐ後に続けて配置すればよい．そうでない場合には，要素サイズをアラインメントの倍数に切り上げたオフセットに配置しなければならない．３番目以降の要素も同様である．したがって配列要素の間隔 (stride) は，要素の正味のサイズ^注5ではなく，それをアラインメントの倍数に切り上げた値でなければならない．

普通の基本データ型ではサイズとアラインメントが同じなのでこの点は問題ないが，構造体を配列にしようとすると問題になる可能性がある．例えば次の構造体を配列にすることを考えよう．

typedef struct {
  int a;    // サイズ，アラインメントとも４バイトとする．
  char b;   // サイズ，アラインメントとも１バイト (Ｃの仕様)．
} S_t;

b は１バイト・アラインメントなので，アラインメント調整は必要なく，a と b の間にパディング (隙間) ができることもない．したがってこの構造体 S_t の正味のサイズは４＋１＝５バイト，アラインメントは最も厳しいメンバである a と同じ４バイトである． S_t を配列にする場合，要素間隔は正味の S_t のサイズ (５バイト) を S_t のアラインメント (４バイト) の倍数に切り上げた８バイトとなる．つまり b の後ろには３バイトのパディングが必要．

実は，Ｃ言語の sizeof 演算子が返すのは構造体の正味のサイズではなく，それを配列にしたときの要素間隔である．つまり sizeof(S_t) == 8 (「sizeof とアラインメントの関係」を参照)．

注5： ここでいう「要素の正味のサイズ」とは，その要素が構造体の場合，「構造体の最終メンバの後のパディング (tail padding) を含めない」という意味で用いる．したがってそれ以外 (つまりメンバ間) のパディングは「正味のサイズ」に含める．

2017/03/26(日) 追記
Swift の MemoryLayout では正味のサイズ (MemoryLayout<構造体名>.size) と要素間隔 (MemoryLayout<構造体名>.stride) をちゃんと区別しているようだ．(C/C++ もこうだったら，#pragma pack などでアラインメントをないがしろにしなくても (配列要素ではない) 構造体の末尾パディングをなくすことができるのに…．)

2012/03/03(土) 追記 (「共用体サイズ」，「共用体パディング」等で検索して来る人がいるので．)

「sizeof(共用体) はメンバのサイズの最大値」と思っている人が多いと思うが， それだけでは不正確．上記の構造体の場合と同様，sizeof の仕様により共用体全体のアラインメントの倍数に切り上げなければならない．

// 前提：double 型のサイズおよびアラインメントは８バイトとする．
typedef union U {
  char string[17]; // サイズ：17バイト，アラインメント：１バイト．
  double d[2];     // サイズ：16バイト，アラインメント：８バイト．
} U_t;

U_t の正味のサイズはメンバのサイズの最大値 max(17, 16)＝17 バイト．
U_t のアラインメントはメンバのアラインメントの最大値 max(1, 8)＝8 バイト．
sizeof(U_t) は U_t の正味のサイズを U_t のアラインメントの倍数に切り上げた24バイト．
したがって最大メンバ string の後にも７バイトのパディングが入る．
(実例：VC2008 による実験結果)

複合データ型のアラインメントは，それに含まれる要素のアラインメントのうち最大の (つまり最も厳しい) ものに一致する．
- 配列のアラインメントは要素のアラインメントに等しい．
複合データ型の要素のオフセットは，その要素のアラインメントの倍数でなければならない．
- Ｃ言語などでは，構造体メンバのオフセットはそのメンバのアラインメントの倍数に切り上げられる．
- 配列の要素間隔は，要素のアラインメントの倍数でなければならない．
  - 配列の要素間隔は，要素の正味のサイズをアラインメントの倍数に切り上げた値である．
  - Ｃ言語の sizeof(X) は X の正味のサイズではなく，それを X のアラインメントの倍数に切り上げた値である．

構造体のアラインメントに関して，次のように誤解 (中途半端に理解) している人を見かけたことがある．

誤解１：(32ビット CPU では) 構造体は常に４バイト境界に配置される．
　　　　　(別表現：構造体のサイズは常に４の倍数である．)

以前から「構造体４バイト(境界)」とか「構造体４の倍数」などの検索ワードが多かったので， (32ビット CPU では) 構造体のアラインメントは常に４バイトだと思い込んでいる人が多そうで心配になる．さらに悪いことに，冒頭の図１を見て「そうか，だから４バイトなのか！」と早トチリした人もいそうだ．(苦笑)

実際，(このページを読んでもまだ) この誤解をしている人をネット上で２，３人見かけた．
(ということは全国に少なくとも２～３億人は隠れてるってことですね，わかります．)

「32 (64) ビット CPU だから構造体のアラインメントは 4 (8) バイト」などと， CPU のビット数やデータバス幅がそのまま構造体のアラインメントになると考えるのはワードマシンの発想であって，バイトマシンのアラインメント規則ではない． ワードマシンでは，ワード単位でしかメモリにアクセスできないのだから， (構造体に限らず) すべての変数のアラインメントがワード単位になるのはむしろ当然．それどころか，ワードマシンはバイトという概念ができる前から存在していた．

昔のコンピュータはワードマシンが多かった (らしい)．バイトの概念ができる前は当然すべてワードマシン．
ミニコン (1960年代～ 1980年代前半) とか， 1980年代の AI (人工知能) 研究ブームでもてはやされた Lisp マシンとか．
(Symbolics の Lisp マシン，使ってみたかった…．ちなみにこれは36ビット (32ビットではない) のワードマシン．)

しかし今時の汎用 CPU のほとんどはバイトマシンであって，ワードマシンはごく一部のメインフレームや特殊な専用プロセッサぐらいしか残っていないだろう．最近の GPU は (実際のハードウェアはどうか知らないが，Direct3D という API を通して見る限りは) 32ビットワードマシンである． (DSP もワードマシンかもしれないが，使ったことがないのでよく知らない．)

「構造体 32ビット(４バイト)」とか「構造体 64ビット(８バイト)」などで検索して来る人は，一体どんなワードマシンを使っているんだろう？
(GPU 以外で) 32ビットや64ビットのワードマシンって聞いたことないけど…．
そうか，きっと GPU のドライバ開発者か Direct3D プログラマなんだろうね．(笑)

さらに追い討ちをかけると(笑)，そもそも「32bit」，「64bit」と一括りにしている点で最初っからダメ．(64bit の場合について言えば) 自分が使っている処理系が LP64 なのか，LLP64 なのか，それ以外 (ILP64，SILP64 など) なのか，理解してますか？
(もっともこれらは基本データ型のサイズによる分類なので，アラインメントについては結局各処理系のマニュアルで確認する必要がある．)

バイトマシンを使っていて，ここに書いた誤解について身に覚えのある人は，下記の構造体のサイズとアラインメントがいくつになるか，自分が使っている処理系で確認して反省してください．(笑)

// ●前提 (char 以外については処理系依存)
// ・char のサイズおよびアラインメントは１バイト (Ｃの仕様)．
// ・short のサイズおよびアラインメントは２バイトとする．
// ・int，long，float のサイズおよびアラインメントは４バイトとする．
// ・long long，double のサイズおよびアラインメントは８バイトとする．
//   x86 用 gcc では -malign-double オプションを指定すること．
//   (デフォルトでは，double および long long のアラインメントが４バイトになっている．
//    これはデータバスが32ビットだった 386，486 との互換性のためだろう．)


// ●構造体/共用体の定義

struct S1 {
  short s;
  unsigned char uc[3];
};

struct S2 {
  char string[10];
  unsigned char uc;
};

struct S3 {
  double d;
  long long ll;
  char c;
};

// sizeof(共用体) で説明した例
typedef union U {
  char string[17];
  double d[2];
} U_t;


// ●型のサイズとアラインメントを出力するマクロ
// sizeof の値を printf("%d") してる人が多いけど，
// size_t 型 (無符号) であって絶対 int 型じゃないよ！
// それに unsigned int と同じとも限らない．
// size_t 型とは，「メモリ上の任意のデータのサイズ」を表すための移植性のある型．
// (MS-DOS 用の Microsoft C コンパイラでは 64KB までしか表せなかったけど…．(昔話)))
#if defined(__STDC_VERSION__) && (__STDC_VERSION__ >= 199901L)
// C99 以後
// size_t の printf 書式は %zu．
static const char format[] = "sizeof(%s)=%zu, AlignmentOf(%s)=%zu.\n";

#define PrintSizeAndAlignment(type) \
  printf(format, #type, sizeof(type), #type, AlignmentOf(type))

#elif defined(_MSC_VER)
// Visual C/C++
// size_t の printf 書式は %Iu．
static const char format[] = "sizeof(%s)=%Iu, AlignmentOf(%s)=%Iu.\n";

#define PrintSizeAndAlignment(type) \
  printf(format, #type, sizeof(type), #type, AlignmentOf(type))

#else
// その他の処理系
// size_t の printf 書式が不明なので unsigned long にキャストして出力する．
static const char format[] = "sizeof(%s)=%lu, AlignmentOf(%s)=%lu.\n";

#define PrintSizeAndAlignment(type) \
  printf(format, \
         #type, (unsigned long)sizeof(type), \
         #type, (unsigned long)AlignmentOf(type))
#endif


// ●型のサイズとアラインメントを出力する．
int main(void)
{
  // 基本データ型 (整数型)
  PrintSizeAndAlignment(char);
  PrintSizeAndAlignment(unsigned char);
  PrintSizeAndAlignment(short);
  PrintSizeAndAlignment(unsigned short);
  PrintSizeAndAlignment(int);
  PrintSizeAndAlignment(unsigned int);
  PrintSizeAndAlignment(long);
  PrintSizeAndAlignment(unsigned long);
  PrintSizeAndAlignment(long long);
  PrintSizeAndAlignment(unsigned long long);
  printf("\n");

  // 基本データ型 (浮動小数型)
  PrintSizeAndAlignment(float);
  PrintSizeAndAlignment(double);
  PrintSizeAndAlignment(long double);
  printf("\n");

  // 複合データ型 (ユーザ定義)
  PrintSizeAndAlignment(struct S1);
  PrintSizeAndAlignment(struct S2);
  PrintSizeAndAlignment(struct S3);
  PrintSizeAndAlignment(union U);

  return EXIT_SUCCESS;
}

上記の前提を満たす処理系ならば，結果は次のようになるべき．

sizeof(struct S1)＝6，AlignmentOf(struct S1)＝2．(２バイト境界に配置される．サイズは２の倍数．)
sizeof(struct S2)＝11，AlignmentOf(struct S2)＝1．(任意のアドレスに配置される．サイズはメンバのサイズの単純合計．)
sizeof(struct S3)＝24，AlignmentOf(struct S3)＝8．(８バイト境界．サイズは８の倍数．)
sizeof(union U)=24, AlignmentOf(union U)=8. (８バイト境界．サイズは８の倍数．)

そうなる理由は「複合データ型のアラインメントのまとめ」を読めばわかるはず．

VC2008 (Target：x86) による実行結果は次のとおり．

sizeof(char)=1, AlignmentOf(char)=1.
sizeof(unsigned char)=1, AlignmentOf(unsigned char)=1.
sizeof(short)=2, AlignmentOf(short)=2.
sizeof(unsigned short)=2, AlignmentOf(unsigned short)=2.
sizeof(int)=4, AlignmentOf(int)=4.
sizeof(unsigned int)=4, AlignmentOf(unsigned int)=4.
sizeof(long)=4, AlignmentOf(long)=4.
sizeof(unsigned long)=4, AlignmentOf(unsigned long)=4.
sizeof(long long)=8, AlignmentOf(long long)=8.
sizeof(unsigned long long)=8, AlignmentOf(unsigned long long)=8.

sizeof(float)=4, AlignmentOf(float)=4.
sizeof(double)=8, AlignmentOf(double)=8.
sizeof(long double)=8, AlignmentOf(long double)=8.

sizeof(struct S1)=6, AlignmentOf(struct S1)=2.
sizeof(struct S2)=11, AlignmentOf(struct S2)=1.
sizeof(struct S3)=24, AlignmentOf(struct S3)=8.
sizeof(union U)=24, AlignmentOf(union U)=8.

この項目は該当する人が多そうなので以前から追加しようと思っていたんだけど，忙しいので後回しにしていた．
今回追加したきっかけは，同じ誤解をしているコンパイラ(！)を見つけたから．(↓)

[Armadillo:04936] Armadillo-210の構造体について

構造体の配列を共有メモリに展開するプログラムのデバック中に、実サイズより多くの領域を使用している事が解かり
以下のサンプル作りを実行すると、4バイトと表示しました。
struct test{
    char   ChNo[1];
}w_mem;

アラインメントを変更するコンパイル・オプションや #pragma などを指定せずにこうなっているのだとしたら，このコンパイラもまた，構造体のアラインメントは常に４バイトだと誤解している可能性がある． double 型や long long 型のメンバが含まれている構造体のアラインメントを４バイトとして扱うと，不正アラインメントエラーが発生する．こういう災厄を招く勘違いコンパイラは，即刻クビにするのが吉．

誤解２：構造体のサイズは，メンバの中で最大のサイズのものの整数倍である．
誤解３：構造体メンバのオフセットは，そのメンバのサイズの整数倍である．

正解はいずれも，「メンバのサイズ」ではなく「メンバのアラインメント」である．したがってこれらの誤解が「正しい」のは，「サイズ＝アラインメント」である場合，つまりメンバが (普通の) 基本データ型の場合に限られる．メンバが複合データ型や，普通でない (サイズが２の冪乗でない，あるいはアラインメントとサイズが一致しない) 基本データ型の場合には通用しない． (アラインメントについて解説している他のサイトでも，上記のような記述を見かけた．)

誤解４：アラインメントなんて，普通は (Ｃコンパイラの) 最適化オプションで調整される
　　　　　 (ので気にしなくていいと言いたいのかな？)

確かにＣコンパイラは，アラインメントの「調整」はしてくれるが，普通は「最適化」はしない … というより，Ｃ言語の仕様上，してはいけない．ここでいう「調整」とは，上で書いたように「メンバのオフセットをそのメンバのアラインメントの倍数に切り上げる」ことで，Ｃコンパイラが普通に行っている．

一方「最適化」となると，「構造体メンバの順序を入れ替えて，できるだけ隙間ができないようにする」としか解釈できないが， Ｃ言語の仕様上，コンパイラが勝手にメンバの順序を入れ替えることは許されない．

参考：移植性のあるCプログラミング | 構造体メンバの配置

しかし，上の参考ページにも書いてあるが，Ｃコンパイラの中にはそういう最適化をしてくれる非標準拡張機能を持つものもあるらしい．その機能を ON にすると，Ｃの規格に違反することになるので普通じゃありません！

■構造体のパディングをできるだけ避ける方法 (2014/05/03(土) 改定)

パディングを避けるために #pragma pack や gcc 拡張の __attribute__((packed))，アラインメントを (小さくする方向に) 変更するコンパイル・オプションなどを使用するのは，CPU のハードウェアの制約に違反して構造体を強引に力で押しつぶす野蛮な方法なので安易に用いるべきではない．CPU の回路について初歩的な知識があれば，すぐに「タダでまともに動くわけがない」とわかるだろう．つまり #pragma pack 等は，文字どおり「構造体のメンバ配置を詰める (pack)」だけで，普通の方法でメンバにアクセスできることを保証していない場合がある (というより，その方が普通？)．

実例１：Visual C/C++ の #pragma pack
If you change the alignment of a structure, it may not use as much space in memory, but you may see a decrease in performance or even get a hardware-generated exception for unaligned access. You can modify this exception behavior by using SetErrorMode.

訳：構造体のアラインメントを変更した場合，メモリの利用効率は上がるかもしれないが，アラインメントが合っていないメンバにアクセスすると性能低下を引き起こしたり，ハードウェア例外が発生したりする可能性がある．(以下略)

x86/x64 で (SSE 以外の) 非整列メンバにアクセスする場合は遅くなるだけだが，ARM や Itanium の場合，あるいは x86/x64 でも SSE データにアクセスする場合はハードウェア例外が発生する．
実例２：Sun Studio 12: C ユーザーズガイド，2.8.19 pack
注 -
#pragma pack を使用して構造体または共用体のメンバーを自然境界以外の境界で整列させると、通常、これらのフィールドへのアクセスが発生した場合に SPARC 上でバスエラーが起きます。このエラーを避けるには (以下略)

ちなみにこのマニュアル内の「厳密な」の原文は "strict" のはずなので， (アラインメントが)「厳しい (つまり大きい)」と訳すべき．
実例(?) ３
昨日 (2013/8/29(木))，「alignment trap って何 packed」で検索してきた人がいた．アラインメントがなぜ必要なのかを全く理解していない初心者が，パディングを単に無駄な隙間だと思って安易に #pragma pack などを使ったらアラインメント違反例外が発生したんだろうな…．

たとえアラインされていないメンバにアクセスできるとしても，

多かれ少なかれ，速度低下の原因になるのは確実．
メンバの読み書きをアトミックに行えなくなる場合がある^注6．
アラインメントに厳格な CPU の場合は (メンバへのアクセスを複数の命令に分けて行うコードを生成する必要があるため) コードサイズが増加する．(参考：ARM の場合の実例)

それどころか，そもそもコンパイラが #pragma pack 相当の機能をサポートしていないかもしれない．

パディングができるだけ入らないようにしたければ，アラインメントを考慮して自分で構造体メンバの順序を決めるのが正統なやり方． #pragma pack などを使わなくても， 構造体メンバを適切な順序で並べればすべてのメンバ間のパディングを必ず０にできる (問題：数学的に証明せよ)．ただし最後のメンバの後のパディングは sizeof の仕様のため０にできない場合がある． 順序の決め方は中学１年レベルの数学 (倍数と冪乗) が理解できていればわかるはず．

注6： 更新はもちろんだが，読むだけ・書くだけの場合も複数回に分けてアクセスするのでアトミック性は全く保証されない．このようなメンバを割込み (シグナル) ハンドラや他のスレッドなどが変更する可能性がある場合に排他制御もせずに読み出すと，変更前の値でも変更後の値でもなく，両者が混ざったデタラメな値 (例えば下位バイトが変更後の値で上位バイトが変更前の値，など) が得られるおそれがある． (2011/08/07(日) 追記)

実例：LONG 型変数についてアトミック操作を行う Win32 API 関数 InterlockedIncrement() などは，CPU が x86 以外の場合や，たとえ x86 であってもマルチプロセッサの場合，変数が適切にアラインされていないと予期せぬ結果を引き起こす．(2014/03/22(土) 追記)

InterlockedIncrement function

Remarks
The variable pointed to by the Addend parameter must be aligned on a 32-bit boundary; otherwise, this function will behave unpredictably on multiprocessor x86 systems and any non-x86 systems.

参考

How does InterlockedIncrement work internally? (The Old New Thing)
GNU/Linux でのスレッドプログラミング ― NPTL (Native POSIX Thread Library) Programming.
→ 不可分操作，保証付きアトミック操作
x86 (IA-32 アーキテクチャ) の場合については、32 ビット境界にアライメントが調整されたアドレスへの書き込みはアトミックに行われることが保証されています (インテル、『ソフトウェアデベロッパーズマニュアル下巻』)

それから「(アラインメントを) 気にしなくていい」という点については「あなたが気にしなくても，(大抵の) CPU は厳しく気にします！」
それに，次のような点も気にしないといけない．(とりあえず，今思いついたものだけ．)

構造体の内容をバイナリファイルに書き出し，別のソフト (同じ OS または別の OS の) で読む場合．この場合にはアラインメントだけでなく，エンディアンも気にしないと．ちゃんとアラインされていないデータがあったりすると，別のソフトで読み書きしようとするときにちょっと面倒なことになる．
(BMP ファイルの BITMAPFILEHEADER 構造体とか． (-_-#))
構造体の内容をバイナリデータとして，別のソフトや別のコンピュータとの間で送受信する場合．これも本質的には上と同じ．
メモリ管理プログラムを書く場合
このページにも書いたが， malloc() の内部実装に興味を持つ人であっても，アラインメントのことを知らない人が意外に多いことに驚いた．メモリ管理プログラムを書こうとしているそこのあなた，アラインメントを理解しないでやるのは無謀ですよ～．

最初の２つの場合に上記の「最適化オプション」を使うと，メンバの順序が勝手に変えられてとんでもないことになる． Memory Mapped I/O において，ハードウェアレジスタを構造体として記述している場合も同様．

●余談

構造体メンバの順序を入れ替えて隙間を最小にする最適化アルゴリズムは昔趣味で考えたことがあり，仕事でも10年ほど前に使った．いずれこのサイトで公開しようと思って，トップページには開設当初から目次に (淡色表示で) 書いてあるが，いまだに公開していない…．(^^;)
このページへのアクセスが最近急増したので，そろそろ公開しようかな…．

「"構造体" "メンバの順序" "Ｃ言語"」で Google 検索してみたところ，ビットフィールドのメンバの順序を入れ替えて最適化を行うというコンパイラを見つけた． ↓これは違反じゃない … よね？

ルネサステクノロジ - よくあるお問い合わせ検索結果

「複合データ型の各要素のオフセット」でも書いたとおり， sizeof(X) の値は，正味のXのサイズ (バイト数) ではなく，それをXのアラインメントの倍数に切り上げた値である．

なぜ sizeof がそういう仕様なのか，わかりますか？

Ｃ言語の規格では，ｎ個の要素からなる配列 array[] に関して，

n == (sizeof(array) / sizeof(array[0]))

となることを要求している．この仕様は事実上次のことを意味する．
(割り算 (包含除) を習ったばかりの小学３年生でもわかるはず．)

sizeof(X) が返す値は，X の正味のサイズではなく， X を配列要素にした場合の配置間隔 (stride) でなければならない．

両者が異なるのは，構造体型ではよくあることだが，サイズが２の冪乗でない基本データ型でも起こりうるので注意が必要．

余談：Ｃ言語の中・上級者向けのサイトのいくつかで，著者が明らかに上記のことを理解して書いているとわかる記述を見たことがある．しかしなぜか上記のことを明言しているのを見たことがない．なんでだろう？

Ｃの標準ライブラリに含まれる malloc() (およびそのファミリーである calloc()，realloc()) が返すアドレスは， すべてのデータ型に適合するようにアラインされている (malloc() の仕様)．また，コンパイラが alloca() をサポートしていれば，それも同様のアドレスを返すはずである．

多くの32ビット CPU では，(標準的なＣがサポートするデータ型の中で) 最もアラインメントの厳しいデータ型は double および long long 型 (８バイト・アラインメント) である (たぶん)．したがって多くの32ビット CPU 用の malloc() は， ８バイトの倍数のアドレスを返す．(実例：VC の malloc)

この話題については，こちらのページもご覧ください．

ポインタの下位数ビットは常に０なので，これらをポインタが参照するデータの型を表すタグ等に転用することができる．これをタグ付きポインタ (tagged pointer) という． 1970～1980年代の LISP マシンは高速化のためタグ付きポインタをハードウェアで処理していた (タグ・アーキテクチャ tagged architecture)．

標準的なＣ言語では，データ型のサイズを取得する sizeof 演算子はあるものの，アラインメントを取得する演算子はない．そこで私は昔 (1993年)，アラインメントを取得するための処理系・OS 独立なマクロ AlignmentOf() を考案し，今でもメモリ管理によく使っている．

Microsoft C では，同様の機能を持つ演算子 __alignof() という演算子があるが，これは実際のアラインメントと一致しない場合があるようである (現在調査中，バグというわけではなくそういう仕様らしい)．

GCC には __alignof__ という演算子があるが，これについては未調査．

(そのうち暇ができれば書くつもり．)

「複合データ型の各要素のオフセット」で「共用体の場合はメンバのオフセットは常に０」と書いた点について，「C/C++ の規格で保証されているのか？」という質問を受けたので追記．私は C/C++ の規格には全然詳しくないし，規格書も持っていないので，規格に関する質問には直接回答できないことを最初にお断りしておきます． (詳しい方，教えてください．ところで IS って何？ Defect Report って何？おいしいの？)

とりあえず手持ちの本などを調べてみると，次のような記述があった．

プログラミング言語C 第２版 (ANSI 規格準拠)， B. W. カーニハン，D. M. リッチー著，石田晴久訳，共立出版，1989．
実際には，共用体は全メンバーの起点からのオフセットが０である構造体である。(p.180)
新・詳説Ｃ言語 [H&S リファレンス] Third Edition，サミュエル P. ハービンソン，ガイ L. スティール共著，斎藤信男監訳，SOFTBANK，1994．
5.7.1 共用体構成要素の配置 (p.157)
共用体型のオブジェクトは、そこに含まれるどの構成要素にも合った記憶域整列境界から始まる。(中略)
```
      static union U {
        ...
        int C;
        ...
      } object, *P = &object;
      
```
この共用体では、次の２つの等値式が成立する。
```
      (union U *) &(P->C) == P
      &(P->C) == (int *) P
      
```
またこれらの等値式は、構成要素 C の型や、 C の前後の構成要素が何であるかに関係なく成立する。
Union (Wikipedia)
Unions in various programming languages
C/C++
In C and C++, untagged unions are expressed nearly exactly like structures (structs), except that each data member begins at the same location in memory.

なお，C/C++ の規格書の文言に頼らず自分の頭で考えてみると次のようになる．

まず，共用体を本来の目的である「複数の変数が同じメモリ領域を共用する」ためだけに使うのであれば，すべてのメンバのオフセットが同じである必要はない．例えば次の共用体 (各メンバのアラインメントはサイズと同じとする) では， u32 のオフセットは０だが，u16 のオフセットは０または２，u8 のオフセットは０～３のいずれでもよいはずである．

union {
  uint32_t u32;
  uint16_t u16;
  uint8_t  u8;
};

しかし現実には，共用体は昔から type punning (あるデータ型のバイト列を別の型として解釈する) のために多用されている．例えば次のような共用体を用いて float 型のエンディアン変換を行ったり，浮動小数演算ではなくビット演算だけで符号を高速判定したりすることができる．

union {
  float    f;
  uint32_t u32;
  uint8_t  u8[4];
};

このような使い方を規格が容認しているのであれば，すべてのメンバを同じオフセットに配置する必要がある．そしてそれは０以外にはない (共用体のサイズを無駄に大きくしない限り)．もし容認していないとすると，低レベルプログラミング言語として必須の type punning ができなくなってしまう (もっとも，変数のアドレスを別の型のポインタにキャストするという代替手段もあるが)．

注意：この内容は，あくまでも CPU がバイトマシンであることが前提 (注1参照)．

楽天で買う

価格：4,410円（税込、送料別）

省メモリプログラミング―メモリ制限のあるシステムのためのソフトウェアパターン集 (Software patterns series)

posted with amazlet at 10.06.12

ジェイムズノーブルチャールズウィアー
ピアソンエデュケーション
売り上げランキング: 80302

おすすめ度の平均:

メモリ制限のあるシステム

分類が上手い

組み込み向けのデザインパターンとしてはまともです。

すべての設計者・プログラマに必須