符号なし整数とsize_t

最近のCおよびC ++コードは、C文字列関数のパラメーターからSTLまで、ほとんどどこでも/のsize_t代わりに使用しているようです。この理由とそれがもたらす利点について知りたいです。intunsigned int

size_tタイプの結果である符号なし整数型であり、sizeofオペレータ（及びoffsetofあなたのシステムが処理できる最大のオブジェクト（たとえば、8GBのの静的配列）のサイズを格納するための十分な大きさであることが保証されるように、オペレータ）。

size_tタイプは、より、より大きな等しい、または小さくてもよくunsigned int、そして、あなたのコンパイラが最適化のためにそれについての仮定を行うことがあります。

より正確な情報は、C99標準のセクション7.17にあります。その草案は、インターネット上でpdf形式で入手できます。C11標準のセクション7.19にも、pdf草案として入手できます。

クラシックC（ブライアンカーニハンとデニスリッチーがThe C Programming Language、Prentice-Hall、1978年に記述したCの初期の方言）は提供しませんでしたsize_t。導入されたC規格委員会size_t移植性の問題を排除するためにされた

embedded.comで詳細に説明されている（非常に良い例を使用）

要するに、size_t決して負ではなく、ターゲットプラットフォームで可能な最大のオブジェクトのサイズを表すのに十分な大きさ（ただし大きすぎない）の符号なし整数型であるtypedefであるため、パフォーマンスが最大になります。

サイズは負であってsize_tはならず、実際に符号なしの型です。また、size_tは符号なしなので、対応する符号付き型の約2倍の数値を格納できます。これは、符号なし整数の他のすべてのビットと同様に、符号ビットを使用して大きさを表すことができるためです。もう1ビット増えると、表現できる数値の範囲を約2倍にします。

だから、あなたは尋ねます、なぜ単にunsigned int？十分な数を保持できない場合があります。unsigned intが32ビットである実装では、それが表すことができる最大数は4294967295です。IP16L32などの一部のプロセッサは、4294967295バイトよりも大きいオブジェクトをコピーできます。

だから、あなたは尋ねます、なぜ使用しないのunsigned long intですか？一部のプラットフォームではパフォーマンスが低下します。標準Cでは、long少なくとも32ビットを使用する必要があります。IP16L32プラットフォームは、32ビットの長さを16ビットワードのペアとして実装します。これらのプラットフォームのほとんどすべての32ビットオペレーターは、32ビットを2つの16ビットチャンクで処理するため、2つ以上の命令が必要です。たとえば、32ビットのlongを移動するには、通常2つのマシン命令が必要です。1つは各16ビットのチャンクを移動するためのものです。

を使用するとsize_t、このパフォーマンスの低下を回避できます。この素晴らしい記事によれば、「Type size_tは、通常はunsigned intまたはのunsigned long、一部の符号なし整数型のエイリアスであるtypedefですが、場合によってはunsigned long longです。各標準C実装は、十分な大きさの符号なし整数を選択することになっていますが、必要以上に大きくはありません。ターゲットプラットフォーム上で可能な最大のオブジェクトのサイズを表します。」

size_t型は、sizeof演算子によって返される型です。これは、ホストマシンでサポートされている任意のメモリ範囲のサイズをバイト単位で表現できる符号なし整数です。ptrdiff_tが符号付き整数値であり、sizeof（ptrdiff_t）とsizeof（size_t）が等しいという点で、（通常）ptrdiff_tに関連しています。

Cコードを作成するときは、メモリ範囲を扱うときは常に size_tを使用する必要があります。

一方、int型は基本的に、ホストマシンが整数演算を最も効率的に実行するために使用できる（符号付き）整数値のサイズとして定義されます。たとえば、多くの古いPCタイプのコンピューターでは、sizeof（size_t）の値は4（バイト）ですが、sizeof（int）は2（バイト）です。16ビット演算は32ビット演算よりも高速でしたが、CPUは最大4 GiBの（論理）メモリ空間を処理できました。

int型は、実際の精度がコンパイラオプションとマシンアーキテクチャの両方に強く依存するため、効率を重視する場合にのみ使用してください。特にC標準では、次の不変式を指定しています。これらのプリミティブ型。

注：これはJavaの場合とは異なります（実際には、「char」、「byte」、「short」、「int」、および「long」の各タイプのビット精度を指定します）。

タイプsize_tは、可能なオブジェクトのサイズを格納するのに十分な大きさでなければなりません。符号なし整数は、その条件を満たす必要はありません。

たとえば、64ビットシステムでは、intとunsigned intは32ビット幅ですが、size_tは4Gより大きい数値を格納するのに十分な大きさでなければなりません。

glibcマニュアル0.02からのこの抜粋は、トピックを調査するときにも関連する可能性があります。

リリース2.4より前のGCCのsize_tタイプとバージョンに潜在的な問題があります。ANSI Cでは、size_tは常に符号なしの型である必要があります。既存のシステムのヘッダーファイルとの互換性のために、GCCはsize_tをstddef.h' to be whatever type the system's sys / types.hで定義し、それがそうであることを定義します。`sys / types.h 'でsize_tを定義するほとんどのUnixシステムは、それを署名付きの型として定義します。ライブラリ内の一部のコードは、署名されていない型であるsize_tに依存しており、署名されている場合は正しく機能しません。

size_tが符号なしであることを期待するGNU Cライブラリコードは正しいです。符号付きの型としてのsize_tの定義が正しくありません。バージョン2.4では、GCCが常にsize_tを符号なしの型として定義し、fixincludes' script will massage the system'ssys / types.h 'がこれと競合しないようにする予定です。

それまでの間、GNU Cライブラリをコンパイルするときに、size_tに符号なしの型を使用するようにGCCに明示的に指示することで、この問題を回避します。`configure 'は、GCCがsize_tに使用するタイプを自動的に検出し、必要に応じてそれを上書きします。

コンパイラが32ビットに設定されているsize_t場合、のtypedefにすぎませんunsigned int。コンパイラが64ビットに設定されている場合size_tは、のtypedefにすぎませんunsigned long long。

size_tは、ポインターのサイズです。

したがって、32ビットまたは一般的なILP32（整数、ロング、ポインター）モデルでは、size_tは32ビットです。64ビットまたは一般的なLP64（long、ポインター）モデルでは、size_tは64ビットです（整数は32ビットのままです）。

他のモデルもありますが、これらはg ++が使用するものです（少なくともデフォルトでは）。