派生データ型の必要性はなんでしょうか？？

Question

size_tやssize_tなどの変数の必要性についてなのですが・・・
派生型

探してみた定義を載せます。

typedef long ssize_t  //stddef.h

typedef __sszie_t ssize_t  //stdio.h
typdef __SSIZE_T_TYPE __ssize_t  // types.h
#define __SSIZE_T_TYPE __SWORD_TYPE  ..typesizes.h

typedef int __sig_atomic_t  //sigset.h
typedef __sig_atomic_t sig_atomic_t  //signal.h

#define __SIZE_TYPE__ long unsigned int  //stddef.h
typedef __SIZE_TYPE__ size_t

うう〜〜ん
正直、型を覚えるのが大変面倒です。
sig_atomic_tとかシグナルの時にしか使用しなさそうですし・・・・
volatile int と記述すれば良いのではないでしょうか？
SIG31-C. シグナルハンドラ内で共有オブジェクトにアクセスしない

これらの型が存在している理由は何でしょうか？
typedefやdefineされているだけなら、普通の変数で良いような気がします。
不要ではないですか？？

探した環境は Linux 64bit GCC glibcです。

Answer 1

これらの型が存在する理由は、移植性を高めるためです。

ポインタのサイズや取りうるメモリのサイズはマシンごとに異なるので、intやlongといった型で書いてしまうと「環境が違うときにサイズが合わない」ということになってしまいます。そのため、必要なサイズに合わせたsize_tやptrdiff_tを用意して、差を吸収しています。

Comments

[strike1217]

typedef やdefineしただけでどうして差分を吸収できるんですか？

[yumetodo]

同じ理由でstdint.hヘッダにint16_t,uint32_tとかの型も定義されていますね。

[maisumakun]

size_tでソースコードを作っておけば、C言語のどの環境に持っていってもそれは「データサイズを表す符号なし整数」という意味になります。

[yumetodo]

>typedef やdefineしただけでどうして差分を吸収できるんですか？

環境A

typedef long long int64_t;

環境B

typedef __int64 int64_t;

となっていれば使う側は

int64_t foo;

とするだけでいいわけです。

[yumetodo]

これがないと利用者は毎回#ifdefを使ったハックをしないといけなくなり、可読性と移植性(可搬性)が下がります。

[strike1217]

環境A,Bによってライブラリが異なっている・・・ということでしょうか？

[yumetodo]

そうです。処理系によって当然typedefの内容は変わりえるわけです(というか処理系が違うんだからライブラリも普通は違うにきまっている、typedefにかぎらず)。

[maisumakun]

たとえば、今のWindowsやLinuxでも、32ビットでコンパイルするか64ビットにするかによって、データの長さは変わってきます

[strike1217]

では、移植性を考慮しない場合は使用しなくても良いんでしょうか？

[yumetodo]

可読性がないのでやはりだめです。

[yumetodo]

どうしても覚えたくないなら、C++11の文明の利器であるautoによる型推論を使いましょう

[maisumakun]

理屈の上ではそうですが、逆に「いちいちsize_tやsig_atomic_tの実際の型を調べる」ほうが面倒ではありませんか？

[strike1217]

int やlongをそのまま使用するのはもはや時代遅れなのですかね？

[yumetodo]

そうではなく、API/Libraryの戻り値の型に合わせて書く or autoで型推論しましょう、という話。

[maisumakun]

時代遅れというか、ポインタやシグナルなどで使う型は「実際の型と違う型で宣言してしてしまうと、不可解なバグのもとになる」ものなのです。

単なる演算用の変数はintでもlongでも大丈夫です。

[strike1217]

処理系によって違う・・・
真っ先に思いついたのは　linux kernel archディレクトリの中身ですが・・・・

これらの型の定義はglibcの中・・・でしたかな？
glibcってコンパイルする際に、処理系によって変えることができるんですか？

[maisumakun]

size_tはコンパイラレベルで決まるものです（sizeof演算子の返り値はsize_tです）。

[strike1217]

linuxカーネルと同じように、アーキテクチャごとに定義してるわけですかね？

[yumetodo]

処理系ってのはコンパイルする環境と言い換えて差し支えないので、コンパイル時のお話です。

[yumetodo]

処理系がターゲットしている実行環境向けに、標準ライブラリは作られています。

[yumetodo]

>maisumakun
>たとえば、今のWindowsやLinuxでも、32ビットでコンパイルするか64ビットにするかによって、データの長さは変わってきます

はそういう意味です。

[strike1217]

アーキテクチャによって異なるように作られているのはカーネルだけではないんですね。
（カーネルだけかと思っていました。）
glibcも同じ要領で作られているんですね！

[maisumakun]

コンパイラは機械語を吐きますので、マシンアーキテクチャに合わせたものが必要です。

[yumetodo]

(削除されたメッセージ)

[strike1217]

あら、もしかしてglibc内ではなくgccの方かな？

[yumetodo]

あ、いや、頓珍漢なこと言ってるのでコメ消ししました

[strike1217]

ああ〜〜。
わかりました。
処理系依存なものはgccの中に含まれ、処理系依存ではない部分はglibcの中に入れることで分割しているわけですね。

「コンパイラは機械語を吐きますので、マシンアーキテクチャに合わせたものが必要です。」
確かにそうですね！

[strike1217]

gccのソースコードもダウンロードしておきますわｗｗ

[gnaggnoyil]

C言語規格によって処理系(implementation)というのはC言語のソースを規格準拠に解釈する環境であるので、コンパイルだけでもglibcだけでもありません。

[strike1217]

コンパイルだけでも、glibcだけでもない？
どういうことでしょうか？