int のサイズが、C および C++ で使用している OS に依存する理由がわかりません。ポインタのサイズが変化しても問題ありませんが、整数のサイズはなぜですか。16 ビット OS の sizeof(int) = 2 バイトの場合、32 ビット OS の場合、sizeof(int) = 4 バイト。なんでそうなの?
ありがとう。
int のサイズが、C および C++ で使用している OS に依存する理由がわかりません。ポインタのサイズが変化しても問題ありませんが、整数のサイズはなぜですか。16 ビット OS の sizeof(int) = 2 バイトの場合、32 ビット OS の場合、sizeof(int) = 4 バイト。なんでそうなの?
ありがとう。
なんでそうなの?
歴史的な理由。
ANSI C 標準が登場する前およびsize_t
1989 年にint
は、配列へのインデックス付けに使用される型でした。を引数としてmalloc
取り、1 を返しました。したがって、任意の配列にインデックスを付けるのに十分な大きさである必要がありましたが、オーバーヘッドが大きくなりすぎないように十分小さくする必要がありました。ファイル オフセットの場合、通常は was 'd toなどのより大きなタイプです。int
strlen
int
long
typedef
off_t
PDP-11では、C が最初に実装されたのは 1970 年代初頭でint
、プロセッサ レジスタと同じ大きさ (16 ビット) でした。VAXなどのより大きなマシンでは、より大きな配列を可能にするために 32 ビットに拡張されました。
この規則はほとんど放棄されています。C および C++ 標準では、配列のインデックスと長さにsize_t
andを使用します。ssize_t
64 ビット プラットフォームでint
は、多くの場合、幅は 32 ビットのままですが、幅size_t
は 64 ビットです。(ただし、 CBLASなどの多くの古い API は、まだint
インデックスに使用されています。)
C++ 標準によると
1.7.1 の状態:
C++ メモリ モデルの基本的な記憶単位はバイトです。バイトは、少なくとも基本的な実行文字セットのメンバーを含むのに十分な大きさです...
次に、3.9.1.1 は次のように述べています。
文字 (char) として宣言されたオブジェクトは、実装の基本文字セットのメンバーを格納するのに十分な大きさでなければなりません。
char
したがって、実際にはバイトであると推測できます。最も重要なことは、3.9.1.2 にも次のように書かれていることです。
符号付き整数型には、「signed char」、「short int」、「int」、「long int」、および「long long int」の 5 つがあります。このリストでは、各タイプは、リスト内の前のタイプと少なくとも同じ量のストレージを提供します。プレーン int は、実行環境のアーキテクチャによって提案される自然なサイズを持ちます。その他の符号付き整数型は、特別なニーズを満たすために提供されています。
つまり、サイズint
は (a) 少なくとも 1 バイトであることが保証され、(b) 実行されている OS/ハードウェアに自然に合わせられるため、最近では 64 ビットまたは (多くの古いシステムの場合) 32 ビットである可能性が最も高いです。 .
バイトは、ターゲット システムが処理して一意にアドレス指定できるメモリの最小単位です。そのため、1 バイトのサイズはプラットフォームとコンパイラに依存しますが、ほとんどの設定では 8 ビットです。
したがって、1 バイトが 8 ビットであると仮定すると、64 ビットは 8 バイトに等しく、32 ビットは 4 バイトに等しく、16 ビットは 2 バイトに等しいことを意味します。
ファジー レベルでは、「X ビット システム」は、基本値 (レジスタ、int など) がデフォルトで X ビットであるシステムです。したがって、システムがネイティブに使用するビット数は、それらの値を保持するために必要なバイト数にすぐに影響します。
あなたの質問は、さまざまなタイプのデータ構造が CPU に依存する理由として再定式化できます。これは、C が低レベルのプログラミングで使用できる言語であるという事実によって単純に正当化できます。カーネルのデータ型で、Linux のさまざまなタイプの CPU に対してデータ型がどのように定義されているかを確認できます。これは、プロセッサのワード長にリンクしています。