最近のCおよびC++コードは、C文字列関数のパラメーターからSTLまで、ほとんどすべての場所で/size_tの代わりに使用されているようです。この理由とそれがもたらすメリットについて興味があります。intunsigned int
235068 次
8 に答える
421
The size_t type is the unsigned integer type that is the result of the sizeof operator (and the offsetof operator), so it is guaranteed to be big enough to contain the size of the biggest object your system can handle (e.g., a static array of 8Gb).
The size_t type may be bigger than, equal to, or smaller than an unsigned int, and your compiler might make assumptions about it for optimization.
You may find more precise information in the C99 standard, section 7.17, a draft of which is available on the Internet in pdf format, or in the C11 standard, section 7.19, also available as a pdf draft.
于 2008-09-25T07:08:12.997 に答える
105
Classic C (Brian Kernighan と Dennis Ritchie が The C Programming Language、Prentice-Hall、1978 で説明した C の初期の方言) は、size_t. size_t移植性の問題を解消するために導入された C 標準委員会
于 2008-09-25T07:13:02.640 に答える
86
つまり、size_t負になることはなく、ターゲット プラットフォームで可能な最大のオブジェクトのサイズを表すのに十分な大きさ (ただし大きすぎない) の符号なし整数型になるように typedef されているため、パフォーマンスが最大化されます。
サイズは決して負であってはならず、実際にsize_tは符号なしの型です。また、size_tは符号なしであるため、対応する符号付き型の約 2 倍の大きさの数値を格納できます。これは、符号なし整数の他のすべてのビットと同様に、符号ビットを使用して大きさを表すことができるためです。もう 1 ビット増えると、表現できる数値の範囲が約 2 倍になります。
では、単に を使用しないのはなぜunsigned intですか? 十分な数を保持できない場合があります。が 32 ビットの実装でunsigned intは、表現できる最大数は です4294967295。IP16L32 などの一部のプロセッサは、4294967295バイトより大きいオブジェクトをコピーできます。
それで、あなたは尋ねます、なぜ使用しないのunsigned long intですか？一部のプラットフォームでは、パフォーマンスが大幅に低下します。標準 C では、long少なくとも 32 ビットを占有する必要があります。IP16L32 プラットフォームは、各 32 ビット長を 16 ビット ワードのペアとして実装します。これらのプラットフォームのほぼすべての 32 ビット オペレータは、2 つの 16 ビット チャンクで 32 ビットを処理するため、少なくとも 2 つの命令を必要とします。たとえば、32 ビットの長さを移動するには、通常、2 つのマシン命令 (16 ビットのチャンクごとに 1 つ) が必要です。
を使用するとsize_t、このパフォーマンスの犠牲を回避できます。この素晴らしい記事によると、「型size_tは、符号なし整数型のエイリアスである typedef であり、通常はunsigned intまたはunsigned longですが、場合によっては もありunsigned long longます。標準 C の各実装は、十分な大きさの符号なし整数を選択することになっていますが、必要以上に大きくはありません。ターゲット プラットフォームで可能な最大のオブジェクトのサイズを表します。」
于 2010-11-28T03:41:35.613 に答える
51
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」の各型のビット精度を指定します)。
于 2008-09-25T07:31:28.103 に答える
24
タイプsize_tは、可能なオブジェクトのサイズを格納するのに十分な大きさである必要があります。unsignedintはその条件を満たす必要はありません。
たとえば、64ビットシステムでは、intとunsigned intは32ビット幅である可能性がありますが、size_tは4Gより大きい数値を格納するのに十分な大きさである必要があります
于 2008-09-25T07:08:27.147 に答える
4
glibc マニュアル 0.02 からのこの抜粋は、トピックを調査するときにも関連する可能性があります。
リリース 2.4 より前の GCC の size_t タイプとバージョンには潜在的な問題があります。ANSI C では、size_t は常に符号なしの型である必要があります。既存のシステムのヘッダー ファイルとの互換性のために、GCC はstddef.h' to be whatever type the system'ssys/types.h で size_t を定義します。`sys/types.h' で size_t を定義するほとんどの Unix システムは、これを符号付きの型として定義します。ライブラリ内の一部のコードは、size_t が署名されていない型であることに依存しており、署名されていると正しく動作しません。
size_t が符号なしであることを期待する GNU C ライブラリ コードは正しいです。size_t の符号付き型としての定義が正しくありません。バージョン 2.4 では、GCC は常に size_t を unsigned 型として定義し、fixincludes' script will massage the system'sこれと競合しないように sys/types.h' を定義する予定です。
当面は、GNU C ライブラリをコンパイルするときに size_t に符号なしの型を使用するよう GCC に明示的に指示することで、この問題を回避します。`configure' は、GCC が size_t に使用するタイプを自動的に検出し、必要に応じてオーバーライドします。
于 2013-09-24T02:44:37.023 に答える
2
私のコンパイラが 32 ビットに設定されている場合はsize_t、 の typedef に他なりませんunsigned int。コンパイラが 64 ビットに設定されている場合size_t、 の typedef に他なりませんunsigned long long。
于 2016-01-19T20:55:04.440 に答える
-4
size_tは、ポインターのサイズです。
したがって、32ビットまたは一般的なILP32（整数、長整数、ポインター）モデルのsize_tは32ビットです。64ビットまたは一般的なLP64（long、ポインター）モデルでは、size_tは64ビットです（整数は32ビットのままです）。
他のモデルもありますが、これらはg ++が使用するモデルです（少なくともデフォルトでは）
于 2008-09-27T05:21:29.247 に答える