Q&A
ふむーーー。
なるほどです。
C言語の本にこうありました。
バイナリファイルに対してのメモリの内容をそのまま読み書きするときは、構造体のメンバの並びや境界調整に気をつける
おそらく、境界調整による詰め物を考慮せよということなのかな？
直感的に詰め物がない構造体の方が良いと思われます。
間違っていたらご指摘をお願いします。
というわけで、実際に作ってみました。
C
1struct test { 2 char tt; 3 int hj; 4 char gh; 5 char bn; 6 //double nn; 7 };
offsetof()によって各メンバ変数を確認しました。
char tt : 4byte
int hj : 4byte
char gh : 1byte
char bn : 3byte
☆double 型のコメントを外すと、
char tt : 4byte
int hj : 4byte
char gh : 1byte
char bn : 7byte
double nn : 8byte
規則性がよくわからないのですが・・・
double型なしの時は、gh+bnで4btyeとし、４の倍数として、境界調整されている感じです。
double型ありの時は、gh+bnで8byte, tt+hjで8byteなので、８の倍数で境界調整が行われている・・・のかな・・・
メンバ変数の宣言の順番によっても詰め物のバイト数が変わると予想しているのですが、
#これを、詰め物がない理想的な構造体にするには、どうすれば良いのでしょうか？？
メンバ変数の中で最も大きな変数に境界調整は合わせられるという理解で正しいでしょうか？？
構造体を作るときにいちいちoffsetofマクロでアライメントを確認するのが、非常に大変な作業なので、構造体を作るときにメンバ宣言のルールのようなものがありましたら、教えてください。
一応windows 64bitで実験しました。
[追記]
Linux 64 bit でもっとメンバ変数を多くして実験してみたところ、
double, float, int, short, unsigned char, char
の順に下から大きい順に並べて構造体を作成してみたところ、gccコンパイラでのoffsetofの結果は、詰め物バイト数を最小にすることができました。
大きいバイト数から数えて（下から）、最大のバイト数の倍数（この場合、double型の8の倍数）になるように構造体の各メンバ変数を作成、調整をしていけば良さそうです。
どうしても、詰め物を入れざるを得ない状況（メンバ変数の全バイトが倍数にならない）で、詰め物を0byteにするのは実質、不可能なんでしょうか？
例えば、詰め物を0byteに出来るように、あえて使わないメンバ変数を作成し、0で初期化した場合、それをバイナリファイルへの出力としたら、中間に余計な0が入ってしまいます。
これでは、ダミー変数を用意しても詰め物と同じ結果になりませんか？
[追記２]
いろいろ出てきますが、詰め物の最小化とメンバ変数の順序には関係性がありそうです。
maismakunさんやケイロニアンさんの回答をもとにすると、CPUとメモリ、メモリと記憶装置、の両方とも理想的な構造体を作成するのは、難しいと思われます
64bit CPUに話を絞るのですが、8^2なので、実行単位は8byteだと思います。
構造体全体のサイズを8の倍数にし、さらに詰め物を最小にするような構造体の作成はやや大変だと思います。
メンバ変数の順序以外に理想形に近づける方法は他にありますでしょうか？
回答4件
8
詰め物がない理想的な構造体
人間にとっては理想的かもしれませんが、CPUにとっては全くそうではありません。
データのずれに寛容なx86ですら、4バイト境界に合っていない32ビット整数の読み込みには境界を守ったデータより時間がかかりますし、x64のSSE系の命令や、RISCのCPUでは境界が合わないと例外を投げてしまいます。メモリ1バイトが惜しいような時代ではないのですし、CPUもコンパイラも速度優先で設計されているのです。
投稿2017/05/09 07:53
編集2017/05/09 07:57
総合スコア142985
5
直感的に詰め物がない構造体の方が良いと思われます。
何をもって「良い」とするかは意見が分かれますね。コンパイラーは無意味なことはしません。パディング（詰め物）は必要だから入れているのです。他の方も書かれている通り、ターゲットのCPUで最もパフォーマンスが引き出せるように調整してくれているのです（必ずしもプログラマーの意図通りではないかもしれませんが）。プログラムの中だけでしか使わない構造体なら、極端に搭載メモリが少ないマシンでもない限りそれが問題になることはほとんどないので、基本的にはコンパイラーに任せるのが一番良い方法です。
ところがバイナリファイルとなると話は違ってきます。ファイルに出力するということは、別のマシンとのデータのやりとりに使うかもしれません。構造体のパディングは処理系依存なので、同じヘッダーファイルをインクルードしてコンパイルしても異なる配置になる可能性があります。
そうなると、あるマシンで出力したバイナリファイルを別のマシンで読ませるとまったくでたらめな内容になってしまうということが起こり得ます。あるいは、まったく同じプログラムを32bit版と64bit版のようにコンパイルを分けただけで、同じマシンで動作するにもかかわらずバイナリファイルの内容が異なるため互換性がなくなる、といった事態も起こり得ます。
バイナリファイルに対してのメモリの内容をそのまま読み書きするときは、構造体のメンバの並びや境界調整に気をつける
これの意図することはそういうことです。
理想を追い求めていらっしゃるようですが、何が理想なのかは状況に応じて変わってきます。コンパイラーは「CPUにとって理想的な配置」になるように自動的にパディングを入れています。今時の64bit向けコンパイラーなら、メンバ変数にdoubleなどの8バイトのデータ型があれば、構造体全体のサイズも自動で8の倍数になります（してくれます）。なるべくパディングが入らないように気をつけることは有意義ですが、やりすぎて関連する情報があちこちに散らばったりして読みづらくなったら、それはそれで「理想」とはほど遠い気がします。マシンサイクル単位でチューニングしなければならないような特殊な状況でもない限りは、利用する立場で考えて読みやすい構造体を設計することが、結果的には理想に近づくのだろうと思います。ファイルや通信などでのデータのやりとりでは、今のトレンドはXMLやJSONなどのテキスト形式ですから、**『バイナリファイルを使うことは構造体の理想以前にプログラムの仕様としてどうなの？』**という話になってしまいます。
投稿2017/05/10 02:33
総合スコア5936
回答へのコメント
1つだけよろしいですか？
バイナリファイルへの読み出し、書き込みに構造体を使用するのはもう時代遅れなのでしょうか？？
目的にもよります。
例えば、別アプリや他システムとのやりとりはせずに内部処理のためだけの一時ファイルのような使い方なら、バイナリファイルとして構造体（メモリイメージ）をそのまま読み書きすることに問題はありませんし、パフォーマンスの観点からあえてそうすることもあり得ます。
そうですか！
こちらも場合によるわけですね！
3
これを、詰め物がない理想的な構造体にするには、どうすれば良いのでしょうか？？
コンパイラによりますがVC系なら#pragma pack(サイズ)によりパックサイズを制御できます。
以下、(1)の場合はパディングなしになります。
C++
1# pragma pack (1) 2struct x_ 3{ 4 char a; // 1 byte 5 int b; // 4 bytes 6 short c; // 2 bytes 7} MyStruct; 8# pragma pack ()
バイナリファイルによる一括入出力したいデータ（構造体）では、安直かもしれませんが、うちでもいまだにわりと普通に利用しています。
投稿2017/05/09 11:21
総合スコア37401
回答へのコメント
おお！
試してみます。
これは、「境界調整なし」ということなんですか？
そうですね。「境界調整なし」＝隙間なしです。
おお！！
出来ました。
Linuxの場合（gcc）はどうやるんですか？
すみません。gccの場合は分かりません。
そうですか！
わかりました。
gccでも同じpragmaを使えます(VCとの互換性のため)
https://gcc.gnu.org/onlinedocs/gcc-4.4.4/gcc/Structure_002dPacking-Pragmas.html
gccでも使えるのですね。情報ありがとうございます。
3
こんにちは。
これを、詰め物がない理想的な構造体にするには、どうすれば良いのでしょうか？？
順序を変えればOKです。（ただし、最適な順序は処理系によって異なるかも知れません。）
C++
1struct test { 2 char tt; 3 char gh; 4 char bn; 5 int hj; 6 double nn; 7 };
これでpaddingはbnの次に１バイト確保されるだけの処理系が多いです。
CPUはデータをアクセスする時「データバス幅」単位でアクセスします。データバス幅はざっくり１サイクルでアクセスできるデータの最大ビット数と考えても大きくは外れません。（昨今の複雑なCPUではそんなに単純な話ではないですが。）
例えば、PCの場合、int型が4バイトでデータバス幅が32ビットあり、データは32ビット単位きれいに並んでメモリに置かれています。その32ビット区切りにきれいに入っている場合は1サイクルでアクセスできます。そうでない場合は跨っている２つの32ビット区切りをそれぞれアクセスする必要があるので遅くなります。
で、double型ですが、これは通常64ビットあります。昔の32ビットバス幅のCPUなら32ビット境界に配置していれば最速だったのですが、最近のCPUはdoubleは64ビット境界に配置した方が高速です。（詳しい理由は私も把握していません。PCのデータバスはシリアルなので複雑なのです。）
以上をまとめると、int型は32ビット（4バイト）境界、double型は64ビット（8バイト）境界に配置するのが最も高速です。
そして、コンパイラはデフォルトではデータをその境界に配置します。もちろん、構造体先頭も適切な境界へ配置されます。
確かgccはスタックを16バイト単位に調整してから、ローカル変数を配置していたと思います。それはこの境界に配置することで高速アクセスできるようにするためです。
確かgccのlong doubleは16バイト境界だったはずなのでそれを考慮しているのではないかと思います。
投稿2017/05/09 09:10
総合スコア23259
回答へのコメント
構造体の場合、メンバ変数のバイト数が小さい順に上から並べれば、必ず詰め物のサイズは最小に抑えられるのでしょうか？
そう言う視点で考えたことは無かったのですが、なんとなくそうなりそうな気はします。
でも、アライメントは処理系依存なので、「常に」そうであることを証明するのはかなり難しいと思いますし、そもそも正しくないかも知れません。
ああ～～
アーキテクチャやCPUの話が混ざると分かりにくくなるんですよね・・・
「なんとなくそうなりそうな気はします。」
そうですか！
分かりました。
うろ覚えなので引用元を特定できないのですが「構造体のメンバーの配置が宣言した通りになると思うのは間違い」というのがあったと思います。←確か処理系依存？・・・確認しました（http://portable-c.jugem.jp/?eid=17）が私の間違いですｍｍ
「メンバ変数の中で最も大きなバイト数の変数に境界調整は合わせられる」としたら、構造体を作るときに詰め物を最小にすることはできそうですが・・・
この理解は正しいのでしょうか？
clang++はパディングあると” warning: padding struct 'Percentage' with 4 bytes to align 'Sum' [-Wpadded]”などというワーニング投げてきます＠＠；・・・intの次にdoubleがある構造体ですd^^
この場合、intを２個用意して（１つはダミー）doubleの前におくとワーニングが消えます。
そうなんですか！
windows のcl オプションなしだと出てこないですね・・・
コンパイラによっても違うという事なんですかね・・・
「これでpaddingはbnの次に１バイト確保されるだけの処理系が多いです。」
すいません。少し気になったのですが、
この場合、tt+gh = 8byte, bn+hj = 8byte, nn = 8byteだと思ったのですが、
bnの方には、余分に3byteの詰め物が入るのではないのですか？
どうして、1byteなのでしょうか？
あ、そうかごめんなさいいい
char型なので、違いますね
tt+gh+bn = 4byte, hj = 4byte, nn = 8byte だから 詰め物が1byteなのですね！
失礼しました。
私の場合は、（コンパイルオプションで）ワーニングをできる限り出すようにしているのでそのせいだと思います。通常の３２・６４ビット処理系ならできるだけ８バイト境界にしておけば、パディングについてはそれほど考えなくてもいいと思います。・・・考え出すとキャッシュのラインサイズまで考えなくちゃならない；；・・・もとが「バイナリファイルの読み書き」の話なのでプログラムAが出力したデータをBプログラムで読んだりする場合、プログラムを作った処理系が違えば構造体の構成も変わるから？・・・という事じゃないのでしょうか？
intの次にdoubleがある構造体では、普通にint型のメンバに4byteの詰め物を入れれば、良いのではないんですかね？
なぜwarningになるのかが分からないんですが・・・
私も（-Weverythingをコンパイラオプションにした時）このワーニングに初めて出くわした時は、ゲ？！とか思ったんですが、めんどくさいので無効にしないで使っています。最近はメモリ節約（＾＾；のヒント程度に考えています。
あなたの回答
tips
プレビュー
下記のような回答は推奨されていません。
このような回答には修正を依頼しましょう。
2017/05/09 08:02
2017/05/09 09:36
2017/05/09 09:42
2017/05/09 09:58 編集
2017/05/09 10:11
2017/05/09 10:19
2017/05/09 10:41
2017/05/09 10:49
2017/05/09 10:51
2017/05/09 11:04
2017/05/09 11:19
2017/05/10 01:06
2017/05/11 07:40 編集
2017/05/11 12:15