自然尺寸：int [英] Natural size: int

问题描述

在现代32位PC上，以下设置很常见：


char：8-bit

短：16位

int：32位

长：32位


" char"通常用于存储文本字符。

" short"通常用于存储大数字数组，或者可能是宽文本字符（通过wchar_t）。

" int"通常用于存储整数。

long通常用于存储大于65535的整数。


现在有64位机器进入，整数类型应该如何分配？b $ b？ int是有意义的。应该是64位......但应该用char来完成

和短？以下是一个合理的设置吗？


字符：8位

短：16位

int：64-比特

长：64位


或者也许应该短是32位？或者应该char成为16位（即

16 == CHAR_BIT）。


另一个与半相关的问题：


如果我们有一个变量，它将元素的数量存储在一个

数组中，那么我们应该使用size_t吗？在size_t的系统上映射到

long unsigned而不是int unsigned，在大多数情况下它看起来效率很低

。 int unsigned保证我们至少65535阵列

元素 - 我们有一个比例大于

的数据的百分比是多少？可能2％？因此，使用unsigned而不是size_t来存储数组长度（或者减去

指针的正面结果）是没有意义的吗？


-


Frederick Gotham

解决方案

Frederick Gotham写道：
< blockquote class =post_quotes>
在现代32位PC上，以下设置很常见：


char：8-bit

短：16位

int：32位

长：32位


" char"通常用于存储文本字符。

" short"通常用于存储大数字数组，或者可能是宽文本字符（通过wchar_t）。

" int"通常用于存储整数。

long通常用于存储大于65535的整数。


现在有64位机器进入，整数类型应该如何分配？b $ b？ int是有意义的。应该是64位......但应该用char来完成

和短？以下是一个合理的设置吗？


字符：8位

短：16位

int：64-比特

长：64位


或者也许应该短是32位？或者应该char成为16位（即

16 == CHAR_BIT）。

对于Windows系统，微软决定用64位机器来支付
将是

char 8，简称16，int 32，long 32，__ int64 64

对于unix系统，gcc决定

char 8，short 16，int 32，long 64，long长64

>

另一个与半相关的问题：


如果我们有一个变量应该将元素的数量存储在

数组中，那么我们应该使用size_t吗？在size_t的系统上映射到

long unsigned而不是int unsigned，在大多数情况下它看起来效率很低

。 int unsigned保证我们至少65535阵列

元素 - 我们有一个比例大于

的数据的百分比是多少？可能2％？因此，使用unsigned而不是size_t来存储数组长度（或者减去

指针的正面结果）是没有意义的吗？

32位机器没有区别，因为寄存器将是32

位。如果只填充16位，则另一个浪费。


如果将索引数据存储在全局变量或磁盘的内存中，

其中空格为更重要的是，你可以*使用短片甚至是字符来获得一些空间增加

。但要注意对齐问题。

编译器会在大多数机器中将数据与32位对齐，因此增益

可能非常好。

Frederick Gotham < fg ******* @ SPAM.com在留言中写道

新闻：Xs ******************* @ news.indigo .ie ...

>

在现代32位PC上，以下设置很常见：


字符：8位

短：16位

int：32位

长： 32位


" char"通常用于存储文本字符。

" short"通常用于存储大数字数组，或者可能是宽文本字符（通过wchar_t）。

" int"通常用于存储整数。

long通常用于存储大于65535的整数。


现在有64位机器进入，整数类型应该如何分配？b $ b？ int是有意义的。应该是64位......但应该用char来完成

和短？以下是一个合理的设置吗？


字符：8位

短：16位

int：64-位

长：64位

如果你使用int你想要一个整数。

如果制造商很友好地提供了64位寄存器，显然他想要你使用64位整数来获得
。

所以看起来很明显该做什么。

>

或许应该短"是32位？或者应该char成为16位（即

16 == CHAR_BIT）。


另一个与半相关的问题：


如果我们有一个变量，它将元素的数量存储在一个

数组中，那么我们应该使用size_t吗？在size_t的系统上映射到

long unsigned而不是int unsigned，它似乎是

低效

大部分时间。 int unsigned保证我们至少65535阵列

元素 - 我们有多少比例的时间我们有一个阵列任何更大的

比

那个？可能2％？因此，使用unsigned而不是size_t来存储数组长度（或者减去

指针的正面结果）是没有意义的吗？

size_t是一个不错的主意 - 一种在内存中保存一个物体大小的类型。

可悲的是，没有想到这些含义 - 如果你不能使用int来

索引一个数组，然后机器制造商做了一些奇怪的事情，用他的地址总线做了很多美元。


字符数据的字符

整数数据的整数

浮点数的双精度。


这就是全部世界真的需要，除了8位数据块的字节在

中，内存大小很重要的罕见情况。

-
www.personal.leeds.ac.uk/~bgy1mm

免费软件游戏下载。

Mal colm写道：

" Frederick Gotham" < fg ******* @ SPAM.com在留言中写道

新闻：Xs ******************* @ news.indigo .ie ...

[整数类型的大小和性质]

size_t是一个不错的主意 - 一种在内存中保存对象大小的类型。

可悲的是，没有想到这些含义 - 如果你不能使用int来

索引一个阵列，然后机器制造商已经做了一些奇怪的事情和他的地址总线很好。

考虑一个64位指针的系统和32位整数 - 不是那个

牵强附会，对吧？在这样的系统上，size_t也可能是64位类型。

您仍然可以*使用* int来索引数组，但不能使用巨大的数组

系统可能允许。 （重要的是另一件事。）

字符数据的
字符

你的意思是像Unicode？

整数数据的整数

25！ = 15511210043330985984000000

浮点数的双精度。

这是什么的两倍？

这是全世界真正需要的，除了内存大小很重要的极少数情况下，8 / b $ 8的数据块的字节。

这几乎不是使用字节的原因。

S.

On modern 32-Bit PC''s, the following setup is common:

char: 8-Bit
short: 16-Bit
int: 32-Bit
long: 32-Bit

"char" is commonly used to store text characters.
"short" is commonly used to store large arrays of numbers, or perhaps wide
text characters (via wchar_t).
"int" is commonly used to store an integer.
"long" is commonly used to store an integer greater than 65535.

Now that 64-Bit machines are coming in, how should the integer types be
distributed? It makes sense that "int" should be 64-Bit... but what should
be done with "char" and "short"? Would the following be a plausible setup?

char: 8-Bit
short: 16-Bit
int: 64-Bit
long: 64-Bit

Or perhaps should "short" be 32-Bit? Or should "char" become 16-Bit (i.e.
16 == CHAR_BIT).

Another semi-related question:

If we have a variable which shall store the quantity of elements in an
array, then should we use "size_t"? On a system where "size_t" maps to
"long unsigned" rather than "int unsigned", it would seem to be inefficient
most of the time. "int unsigned" guarantees us at least 65535 array
elements -- what percentage of the time do we have an array any bigger than
that? 2% maybe? Therefore would it not make sense to use unsigned rather
than size_t to store array lengths (or the positive result of subtracting
pointers)?

--

Frederick Gotham

解决方案

Frederick Gotham wrote:

On modern 32-Bit PC''s, the following setup is common:

char: 8-Bit
short: 16-Bit
int: 32-Bit
long: 32-Bit

"char" is commonly used to store text characters.
"short" is commonly used to store large arrays of numbers, or perhaps wide
text characters (via wchar_t).
"int" is commonly used to store an integer.
"long" is commonly used to store an integer greater than 65535.

Now that 64-Bit machines are coming in, how should the integer types be
distributed? It makes sense that "int" should be 64-Bit... but what should
be done with "char" and "short"? Would the following be a plausible setup?

char: 8-Bit
short: 16-Bit
int: 64-Bit
long: 64-Bit

Or perhaps should "short" be 32-Bit? Or should "char" become 16-Bit (i.e.
16 == CHAR_BIT).

For windows systems, Microsoft decided that with 64 bit machines it
will be
char 8, short 16, int 32, long 32, __int64 64

For unix systems, gcc decided that
char 8, short 16, int 32, long 64, long long 64

>
Another semi-related question:

If we have a variable which shall store the quantity of elements in an
array, then should we use "size_t"? On a system where "size_t" maps to
"long unsigned" rather than "int unsigned", it would seem to be inefficient
most of the time. "int unsigned" guarantees us at least 65535 array
elements -- what percentage of the time do we have an array any bigger than
that? 2% maybe? Therefore would it not make sense to use unsigned rather
than size_t to store array lengths (or the positive result of subtracting
pointers)?

There is no difference in 32 bit machines since a register will be 32
bits. If you fill 16 bits only, the other are wasted.

If you store the index data in memory in global variables or in disk,
where space is more important you *could* have some space gains by
using a short, or even a char. But beware of alignment issues. The
compiler will align data to 32 bits in most machines so the gains
could be very well zero.

"Frederick Gotham" <fg*******@SPAM.comwrote in message
news:Xs*******************@news.indigo.ie...

>
On modern 32-Bit PC''s, the following setup is common:

char: 8-Bit
short: 16-Bit
int: 32-Bit
long: 32-Bit

"char" is commonly used to store text characters.
"short" is commonly used to store large arrays of numbers, or perhaps wide
text characters (via wchar_t).
"int" is commonly used to store an integer.
"long" is commonly used to store an integer greater than 65535.

Now that 64-Bit machines are coming in, how should the integer types be
distributed? It makes sense that "int" should be 64-Bit... but what should
be done with "char" and "short"? Would the following be a plausible setup?

char: 8-Bit
short: 16-Bit
int: 64-Bit
long: 64-Bit

If you use int you want an integer.
If the manufacturer has kindly provided 64 bit registers, obviously he wants
you to use 64-bit integers.
So it seems pretty obvious what to do.

>
Or perhaps should "short" be 32-Bit? Or should "char" become 16-Bit (i.e.
16 == CHAR_BIT).

Another semi-related question:

If we have a variable which shall store the quantity of elements in an
array, then should we use "size_t"? On a system where "size_t" maps to
"long unsigned" rather than "int unsigned", it would seem to be
inefficient
most of the time. "int unsigned" guarantees us at least 65535 array
elements -- what percentage of the time do we have an array any bigger
than
that? 2% maybe? Therefore would it not make sense to use unsigned rather
than size_t to store array lengths (or the positive result of subtracting
pointers)?

size_t was a nice idea - a type to hold a size of an object in memory.
Sadly the implications weren''t thought through - if you can''t use an int to
index an array, then the machine manufacturer has done something weird and
wonderful with his address bus.

characters for character data
integers for integral data
double precision for floating point numbers.

That''s all the world really needs, except byte for chunks of 8-bit data in
the rare cases where memory size matters.
--
www.personal.leeds.ac.uk/~bgy1mm
freeware games to download.

Malcolm wrote:

"Frederick Gotham" <fg*******@SPAM.comwrote in message
news:Xs*******************@news.indigo.ie...

[size and nature of integral types]

size_t was a nice idea - a type to hold a size of an object in memory.
Sadly the implications weren''t thought through - if you can''t use an int to
index an array, then the machine manufacturer has done something weird and
wonderful with his address bus.

Consider a system with 64-bit pointers and 32-bit ints -- not that
far-fetched, right? On such a system size_t might be a 64-bit type as well.
You can still *use* ints to index an array, but not the huge arrays the
system might allow. (Whether that matters is another thing.)

characters for character data

You mean like Unicode?

integers for integral data

25! = 15511210043330985984000000

double precision for floating point numbers.

Which is double of what?

That''s all the world really needs, except byte for chunks of 8-bit data in
the rare cases where memory size matters.

That is almost never the reason why bytes are used.

S.

这篇关于自然尺寸：int的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！