size_t - 为什么？ [英] size_t - why?

问题描述

我曾经认为size_t与积分类型有关，而

std。


有些东西......


a char是8位，

a int> = a char


a long> = int


等


意味着编译器可能只提供8位长，并且仍然符合
。


所以，我认为size_t是''额外'''''''size_t保证有足够的比特来保持这个尺寸一些数组/ malloc''ed记忆''等等。


然而，似乎size_t通常是*一个无符号长 - 所以prop.1

不可能是正确的（有人可以纠正这个 - 或者指向我的正确位置

stds）。


所以，现在我很困惑，是的，我已经google了，我找不到一个理性的

for size_t。我已经搜索了=我的物超所值=

INCITS + ISO + IEC + 9899-1999.pdf的副本，但adobe阅读器的价格却很糟糕

接受'type_t NEAR reasonale'等搜索词的能力。

I used to believe that size_t was something to do with integral types, and
the std.

Something along the lines of ..

a char is 8 bits,

a int >= a char

a long >= int

etc

Meaning that a compiler might only provide 8 bit longs, and still be
compliant.

So, I thought size_t was something ''extra'' ... ''size_t is guaranteed to have
enough bits to be able to hold the size of some array/malloc''ed memory'' etc.

However, it seems as though size_t is *usually* an unsigned long - so prop.1
can''t be right (can someone correct that - or point me to the right bit of
the stds please).

So, now I''m confused, and, yes, I''ve googled, and I can''t find a rational
for size_t. I''ve searched =my great value for money= copy of
INCITS+ISO+IEC+9899-1999.pdf, but the adobe reader sucks in terms of its
ability to accept search terms like ''type_t NEAR rationale'' etc.

推荐答案

" rayw" < RA ********* @ gmail.com>写道：

"rayw" <ra*********@gmail.com> wrote:

我曾经认为size_t与积分类型有关，而且
std。

有些东西。 。

一个字符是8位，

一个int> =一个字符

一个长的> = int



意味着编译器可能只提供8位长，并且仍然符合要求。


编号长度必须大于或等于int，但它必须至少为32位才能为
。这意味着所有char，int和

长的合法大小是合法的，而sizeof（long）== sizeof（int）== sizeof

（char）== 1，但是CHAR_BIT必须至少为32.

然而，似乎size_t通常是*无符号长 - 所以prop.1
可以是对的

I used to believe that size_t was something to do with integral types, and
the std.

Something along the lines of ..

a char is 8 bits,

a int >= a char

a long >= int

etc

Meaning that a compiler might only provide 8 bit longs, and still be
compliant.
No. A long must be larger than or equal to an int, but it must also be
at least 32 bits. This means that it''s legal for all of char, int and
long to have the same size, and sizeof (long) == sizeof (int) == sizeof
(char) == 1, but then CHAR_BIT must be at least 32.
However, it seems as though size_t is *usually* an unsigned long - so prop.1
can''t be right

但这不是正确的推论。 _Usually_一个unsigned long比一个char大
。确实，你的第一个属性是不正确的，但

它并没有遵循任何给定平台上size_t的定义。


Richard

That''s not the right inference, though. _Usually_ an unsigned long is
larger than a char. It''s true that your first property is incorrect, but
it doesn''t follow from the definition of size_t on any given platform.

Richard

rayw写道：

我曾经认为size_t与积分类型有关，而且st /。
/>
有些东西......

一个字符是8位，

不，虽然这很常见。 char是CHAR_BIT位，其中CHAR_BIT = 8.
a int> = a char

不完全。 int至少为16位（它可以容纳的最小值

必须是-32767或更小，最大值32767或更大）。当然，一个字母

也可以是16位。

a long> = int

Nope。长度至少为32位。一个int也可以是32位，但是一个

长可能不是16位，一个int可能。

等

我可以重新确定准确的规则，但你最好重新阅读它们自己（你在下面说明你有一份标准副本）。查询

< limits.h> ;.

意味着编译器可能只提供8位长，并且仍然符合要求。

编号长整数必须至少为32位。但是，编译器可能会提供32位长且仍然符合的字符（即

sizeof long == 1）。

所以，我认为size_t是''额外'''''''size_t保证有足够的位来保持某些数组/ malloc''内存的大小'等。

确切地说，size_t是sizeof使用的类型。非正式地，size_t是

我们可以用来计算字节数的类型。

然而，似乎size_t通常是*无符号长 - 所以prop.1
不可能是正确的（有人可以纠正这一点 - 或者指出我需要stds的正确位置）。

size_t通常是无符号长的，因为32位平台（32位
整数，32位长整数和32位地址）非常常见。在这样的

平台上，unsigned long是size_t的自然选择。

所以，现在我很困惑，是的，我已经google了，我找不到size_t的理性
。我搜索了=我物超所值=
INCITS + ISO + IEC + 9899-1999.pdf的复制品，但adobe读者很难接受像''这样的搜索词。 'type_t NEAR reasonale''等。

I used to believe that size_t was something to do with integral types, and
the std.

Something along the lines of ..

a char is 8 bits,
No, though this is very common. A char is CHAR_BIT bits, where CHAR_BIT= 8. a int >= a char
Not quite. An int is at least 16 bits (the minimum value it can hold
must be -32767 or smaller, the maximum value 32767 or greater). A char
could be 16 bits too, of course.
a long >= int
Nope. A long is at least 32 bits. An int could be 32 bits as well, but a
long may not be 16 bits, and an int may.
etc
I could rehash the exact rules, but you''re better off rereading them
yourself (you state below that you have a copy of the standard). Look up
<limits.h>.
Meaning that a compiler might only provide 8 bit longs, and still be
compliant.
No. Longs must be at least 32 bits long. A compiler may, however,
provide chars that are 32 bits long and still be compliant (that is,
sizeof long == 1).
So, I thought size_t was something ''extra'' ... ''size_t is guaranteed to have
enough bits to be able to hold the size of some array/malloc''ed memory'' etc.
To be precise, size_t is the type used by sizeof. Informally, size_t is
the type we can use to count bytes.
However, it seems as though size_t is *usually* an unsigned long - so prop.1
can''t be right (can someone correct that - or point me to the right bit of
the stds please).
size_t is usually an unsigned long because 32-bit platforms (with 32-bit
integers, 32-bit longs and 32-bit addresses) are very common. On such
platforms "unsigned long" is the natural choice for size_t.
So, now I''m confused, and, yes, I''ve googled, and I can''t find a rational
for size_t. I''ve searched =my great value for money= copy of
INCITS+ISO+IEC+9899-1999.pdf, but the adobe reader sucks in terms of its
ability to accept search terms like ''type_t NEAR rationale'' etc.

size_t在所有平台上不仅仅是一个长的原因是因为至少32位的

算术类型是不一定是自然的选择

用于保持物体大小的类型。


在7.17.4中，标准推荐

用于size_t和ptrdiff_t的类型不应该有一个整数

转换等级大于signed long int的转换等级，除非

实现支持足够大的对象这是必要的。


这明确承认size_t比长期更大的可能性b $ b（尽管建议不要这样做，除非

实际上是必要的，因为较旧的程序或写得不好的新的

程序可能会破坏，如果这不成立）。另一方面，size_t

在小型平台上可能更小，其中单个对象不能超过一定大小的b / b
虽然整体内存可能更大。


size_t是抽象的，所以平台不受人为限制。


S.

The reason size_t is not simply a long on all platforms is because an
arithmetic type of at least 32 bits is not necessarily a natural choice
for the type used to hold the size of an object.

In 7.17.4, the standard recommends
"The types used for size_t and ptrdiff_t should not have an integer
conversion rank greater than that of signed long int unless the
implementation supports objects large enough to make this necessary."

This explicitly acknowledges the possibility of size_t being greater
than a long (though it is recommended that this not be so unless
actually necessary, because older programs or badly written newer
programs might break if this does not hold). On the flip side, size_t
might be smaller on small platforms where single objects cannot exceed a
certain size, although memory as a whole may be larger.

size_t is left abstract so platforms are not artificially constrained.

S.

" Skarmander" <在***** @ dontmailme.com>在消息中写道

news：43 *********************** @ news.xs4all.nl ...

"Skarmander" <in*****@dontmailme.com> wrote in message
news:43***********************@news.xs4all.nl...

rayw写道：

我曾经认为size_t与积分类型有关，
和std。

有些东西沿着..

一个字符是8位，

I used to believe that size_t was something to do with integral types,
and the std.

Something along the lines of ..

a char is 8 bits,

不，虽然这很常见。 char是CHAR_BIT位，其中CHAR_BIT

No, though this is very common. A char is CHAR_BIT bits, where CHAR_BIT

= 8。

a int> = char

a int >= a char

不完全的。 int至少为16位（它可以容纳的最小值必须为-32767或更小，最大值为32767或更大）。当然，char也可以是16位。

Not quite. An int is at least 16 bits (the minimum value it can hold must
be -32767 or smaller, the maximum value 32767 or greater). A char could be
16 bits too, of course.

a long> = int

a long >= int

Nope。长度至少为32位。 int也可以是32位，但是
long可能不是16位，而int可能。

Nope. A long is at least 32 bits. An int could be 32 bits as well, but a
long may not be 16 bits, and an int may.

etc

我可以重新确定准确的规则，但你最好重新阅读它们（你在下面说明你有一份标准副本）。查找
< limits.h>。

I could rehash the exact rules, but you''re better off rereading them
yourself (you state below that you have a copy of the standard). Look up
<limits.h>.

意思是编译器可能只提供8位长，并且仍然符合要求。

Meaning that a compiler might only provide 8 bit longs, and still be
compliant.

<不需要。长号必须至少为32位。但是，编译器可能会提供32位长且仍然符合的字符（即sizeof long
== 1）。

No. Longs must be at least 32 bits long. A compiler may, however, provide
chars that are 32 bits long and still be compliant (that is, sizeof long
== 1).

所以，我认为size_t是''额外'''''''size_t保证有足够的位来保持某些数组/ malloc''内存的大小等等。

So, I thought size_t was something ''extra'' ... ''size_t is guaranteed to
have enough bits to be able to hold the size of some array/malloc''ed
memory'' etc.

准确地说，size_t是sizeof使用的类型。非正式地，size_t是我们可以用来计算字节数的类型。

To be precise, size_t is the type used by sizeof. Informally, size_t is
the type we can use to count bytes.

然而，似乎size_t通常是*一个无符号的长 - 所以
道具.1不可能是正确的（有人可以纠正 - 或者请指出stds的正确位置）。

However, it seems as though size_t is *usually* an unsigned long - so
prop.1 can''t be right (can someone correct that - or point me to the
right bit of the stds please).

size_t通常是无符号长的，因为32位平台（具有32位整数，32位长和32位地址）非常常见。在这样的平台上，unsigned long是size_t的自然选择。

size_t is usually an unsigned long because 32-bit platforms (with 32-bit
integers, 32-bit longs and 32-bit addresses) are very common. On such
platforms "unsigned long" is the natural choice for size_t.

所以，现在我很困惑，是的，我已经google了，我找不到理性的对于size_t。我搜索了=我物超所值=
INCITS + ISO + IEC + 9899-1999.pdf的复制品，但adobe读者很难接受像''这样的搜索词。 'type_t NEAR reasonale''等。

So, now I''m confused, and, yes, I''ve googled, and I can''t find a rational
for size_t. I''ve searched =my great value for money= copy of
INCITS+ISO+IEC+9899-1999.pdf, but the adobe reader sucks in terms of its
ability to accept search terms like ''type_t NEAR rationale'' etc.

size_t在所有平台上不仅仅是一个长的原因是因为至少32位的算术类型不一定是自然的选择
用于保持对象大小的类型。

在7.17.4中，标准建议
用于size_t和ptrdiff_t的类型不应该有整数转换排名大于signed long int的转换排名，除非
实现支持大到足以使其成为必要的对象。

这明确承认size_t大于
的可能性很长一段时间（虽然建议不要这样，除非实际上是必要的，因为如果不成功，旧程序或写得不好的新程序可能会中断）。另一方面，size_t可能在小型平台上较小，其中单个对象不能超过一定大小，尽管整个内存可能更大。

size_t是抽象的所以平台不受人为限制。

The reason size_t is not simply a long on all platforms is because an
arithmetic type of at least 32 bits is not necessarily a natural choice
for the type used to hold the size of an object.

In 7.17.4, the standard recommends
"The types used for size_t and ptrdiff_t should not have an integer
conversion rank greater than that of signed long int unless the
implementation supports objects large enough to make this necessary."

This explicitly acknowledges the possibility of size_t being greater than
a long (though it is recommended that this not be so unless actually
necessary, because older programs or badly written newer programs might
break if this does not hold). On the flip side, size_t might be smaller on
small platforms where single objects cannot exceed a certain size,
although memory as a whole may be larger.

size_t is left abstract so platforms are not artificially constrained.

感谢两者，特别是 S。现在全部清除了 - 感谢stds

参考 - 虽然找到它你必须*不*使用Adobe读者 -

或者你耐心等待一个圣人。

Thanks to both, esp. ''S''. All clear now - and thanks for the stds
reference - although to find it you must *not* be using the Adobe reader -
or maybe you''ve the patience of a saint.

这篇关于size_t - 为什么？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！