タイトルは実際には少し誤解を招くものですが、短くしたかったのです。size_t を使用する理由について読んだことがありますが、次のようなステートメントをよく見つけました。
size_t任意の配列を含む任意のオブジェクトの最大サイズを表現できることが保証されています
それが何を意味するのかよくわかりません。一度に割り当てることができるメモリの量に何らかの上限があり、size_t はそのメモリ ブロック内のすべてのバイトをカウントするのに十分な大きさであることが保証されていますか?
フォローアップの質問:
どのくらいのメモリを割り当てることができるかを決定するものは何ですか?
コンパイラ/プラットフォームが持つことができる最大のオブジェクトが 4 GB だとしましょう。size_t次に32ビットです。ここで、サイズ 2^43 - 1 のオブジェクトをサポートできる 64 ビット プラットフォームでプログラムを再コンパイルするとします。size_t少なくとも 43 ビットの長さになります (ただし、通常、この時点では 64 ビットになります)。ポイントは、プログラムを再コンパイルするだけでよいということです。intすべての をlong( int32 ビットでlong64 ビットの場合) または からint32_tに変更する必要はありませんint64_t。(なぜ 43 ビットなのか自問自答している場合は、Windows Server 2008 R2 64 ビットがサイズ 2^63 のオブジェクトもサイズ 2^62 のオブジェクトもサポートしていないとしましょう... 8 TBのアドレス可能スペースをサポートしています...つまり 43少し！）
DWORDWindows 用に作成された多くのプログラムでは、ポインターは(32 ビットの符号なし整数)と同じ大きさであると見なされていました。これらのプログラムは、大量のコードを書き直さない限り、64 ビットで再コンパイルすることはできません。DWORD_PTR彼らが(ポインターを含むために必要なだけ大きいことが保証されている符号なしの値)を使用していれば、この問題は発生しなかったでしょう。
「size_tポイント」も同様です。しかし違う！
size_tポインターを含むことができるとは限りません!!
（DWORD_PTRMicrosoft Windowsのは）
これは、一般に違法です。
void *p = ...
size_t p2 = (size_t)p;
たとえば、古い DOS「プラットフォーム」では、オブジェクトの最大サイズは 64k であったため、16 ビットである必要size_tがありましたが、ファー ポインターは少なくとも 20 ビットである必要がありました。これは、8086 のメモリ空間が 1 MB ( 8086 のメモリがセグメント化されていたため、far ポインタの最後は 16 + 16 ビットでした)
基本的にsize_t、 は、任意の配列にインデックスを付け、任意のデータ型のサイズを取得するのに十分な大きさであることが保証されていることを意味します。
およびその他の整数型のサイズは、インデックス付けできるサイズよりも小さい可能性があるintため、just を使用するよりも優先されます。intたとえば、int通常は 32 ビット長であり、64 ビット マシンで大きな配列にインデックスを付けるには不十分です。(これは実際には、プログラムを 64 ビットに移植する際に非常によくある問題です。)
まさにその理由です。特定のプログラミング言語のオブジェクトの最大サイズは、使用している OS、CPU アーキテクチャ、およびコンパイラ/リンカーの組み合わせによって決まります。
size_t は、可能な限り最大のオブジェクトのサイズ値を保持するのに十分な大きさに定義されています。
これは通常、size_t が使用可能な最大の int 型と同じになるように typedef されていることを意味します。そのため、32 ビット環境では通常 4 バイト、64 ビット システムでは 8 バイトになります。
size_tコンパイルするプラットフォーム用に定義されています。したがって、そのプラットフォームの最大値を表すことができます。
size_t は sizeof 演算子 (7.17 c99 を参照) の戻り値であるため、システムが表現できる最大のオブジェクトを記述する必要があります。