标准整数类型vs< stdint.h>类型 [英] Standard integer types vs <stdint.h> types
问题描述
char和unsigned char有特定用途：char对于表示基本执行字符集的字符的
非常有用
unsigned char对于表示个体的值很有用
字节。标准整数类型的其余部分通用
目的。它们唯一的要求是满足最小范围的b $ b值，并且int具有执行环境的
架构所建议的自然大小。使用这些类型而不是[u] int_fastN_t类型的< stdint.h>？
如果我只想签名，
的原因是什么？具有至少16宽度的整数，那么为什么
选择int而不是int_fast16_t？ int_fast16_t是最快的
有符号整数类型，其宽度至少为16，而int只是一个
有符号整数类型，其宽度至少为16。似乎选择
int_fast16_t至少和选择int一样好。对于N = 8,16,32,64，以及对应的无符号类型，这个参数可以是
。
< stdint.halso提供[u] int_leastN_t类型，这对于保持较小存储空间的
是最有用的。
使用我能看到的标准整数类型的唯一好处是<随着C标准的进展，它们的范围可能会扩展，因此
使用它们的代码可能会随着时间的推移而保持有用。例如< stdio.h>
的fseek使用long作为其偏移参数，因此如果long的范围增长
那么fseek将自动提供更广泛的范围补偿。
注意（或者可能不是）在Windows
世界中，长期存在于通用目的的想法也有些有趣已被销毁，而且已经成为必须拥有32位的类型。
char and unsigned char have specific purposes: char is useful for
representing characters of the basic execution character set and
unsigned char is useful for representing the values of individual
bytes. The remainder of the standard integer types are general
purpose. Their only requirement is to satisfy a minimum range of
values, and also int "has the natural size suggested by the
architecture of the execution environment". What are the reasons for
using these types instead of the [u]int_fastN_t types of <stdint.h>?
If I want just a signed integer with at least 16 width, then why
choose int instead of int_fast16_t? int_fast16_t is the "fastest"
signed integer type that has at least 16 width, while int is simply a
signed integer type that has at least 16 width. It seems that choosing
int_fast16_t is at least as good as choosing int. This argument can be
made for N=8,16,32,64, and for the corresponding unsigned types.
<stdint.halso offers [u]int_leastN_t types, which are useful when
keeping a small storage size is the greatest concern.
The only benefit of using the standard integer types I can see is that
their ranges may expand as the C standard progresses, so code that
uses them might stay useful over time. For example fseek of <stdio.h>
uses a long for its offset parameter, so if the range of long grows
then fseek will automatically offer a wider range of offsets.
It''s also interesting to note (or maybe not) that in the Windows
world, the idea of long being general purpose has somewhat been
destroyed and long has become a type that must have exactly 32 bits.
推荐答案
< eu *** **@gmail.com在消息中写了
<eu*****@gmail.comwrote in message
char和unsigned char有特定用途：char对于表示基本执行字符的
很有用字符集和
unsigned char对于表示单个
字节的值很有用。标准整数类型的其余部分通用
目的。它们唯一的要求是满足最小范围的b $ b值，并且int具有执行环境的
架构所建议的自然大小。使用这些类型而不是[u] int_fastN_t类型的< stdint.h>？
如果我只想签名，
的原因是什么？具有至少16宽度的整数，那么为什么
选择int而不是int_fast16_t？ int_fast16_t是最快的
有符号整数类型，其宽度至少为16，而int只是一个
有符号整数类型，其宽度至少为16。似乎选择
int_fast16_t至少和选择int一样好。对于N = 8,16,32,64，以及对应的无符号类型，这个参数可以是
。
< stdint.halso提供[u] int_leastN_t类型，这对于保持较小存储空间的
是最有用的。
使用我能看到的标准整数类型的唯一好处是<随着C标准的进展，它们的范围可能会扩展，因此
使用它们的代码可能会随着时间的推移而保持有用。例如< stdio.h>
的fseek使用long作为其偏移参数，因此如果long的范围增长
那么fseek将自动提供更广泛的范围补偿。
注意（或者可能不是）在Windows
世界中，长期存在于通用目的的想法也有些有趣已经被销毁了，而且已经变成了一个必须正好有32位的类型。
char and unsigned char have specific purposes: char is useful for
representing characters of the basic execution character set and
unsigned char is useful for representing the values of individual
bytes. The remainder of the standard integer types are general
purpose. Their only requirement is to satisfy a minimum range of
values, and also int "has the natural size suggested by the
architecture of the execution environment". What are the reasons for
using these types instead of the [u]int_fastN_t types of <stdint.h>?
If I want just a signed integer with at least 16 width, then why
choose int instead of int_fast16_t? int_fast16_t is the "fastest"
signed integer type that has at least 16 width, while int is simply a
signed integer type that has at least 16 width. It seems that choosing
int_fast16_t is at least as good as choosing int. This argument can be
made for N=8,16,32,64, and for the corresponding unsigned types.
<stdint.halso offers [u]int_leastN_t types, which are useful when
keeping a small storage size is the greatest concern.
The only benefit of using the standard integer types I can see is that
their ranges may expand as the C standard progresses, so code that
uses them might stay useful over time. For example fseek of <stdio.h>
uses a long for its offset parameter, so if the range of long grows
then fseek will automatically offer a wider range of offsets.
It''s also interesting to note (or maybe not) that in the Windows
world, the idea of long being general purpose has somewhat been
destroyed and long has become a type that must have exactly 32 bits.
是的，我们正在快速走下去破坏C基本整数
类型。
一旦开始发明像int_fast16_t这样的类型，人们就会使用它们，并且
语言变得越来越难以阅读。
我自己的观点是你应该能够坚持使用char来表示字符和
int for integers，in几乎所有情况。然而，如果你可以使用int作为任意数组索引和快速类型，这只是可行的。
-
免费游戏和编程好东西。
http：// www。 personal.leeds.ac.uk/~bgy1mm
Malcolm McLean写道，2008年1月18日09:09：
Malcolm McLean wrote, On 18/01/08 09:09:
< eu ***** @ gmail.com写在消息中
<eu*****@gmail.comwrote in message
> char和unsigned char有特定用途：char对于表示基本执行字符集的字符非常有用。
unsigned char对于表示单个字节的值很有用。
>char and unsigned char have specific purposes: char is useful for
representing characters of the basic execution character set and
unsigned char is useful for representing the values of individual
bytes.
是的。此外，指向char的指针通常由string取代。
函数包括（但不限于）标准库中的那些。
Yes. Also pointer to char is the type normally taken by "string"
functions including (but not limited to) those in the standard library.
>标准整数类型的其余部分是一般的目的。它们的唯一要求是满足最小范围的值，并且int具有由执行环境的
体系结构建议的自然大小。
>The remainder of the standard integer types are general
purpose. Their only requirement is to satisfy a minimum range of
values, and also int "has the natural size suggested by the
architecture of the execution environment".
是。
Yes.
>什么是使用这些类型而不是< stdint.h>的[u] int_fastN_t类型的原因
>What are the reasons for
using these types instead of the [u]int_fastN_t types of <stdint.h>?
好吧，stdint.h只是在1999年的标准中引入的，这个标准是没有完全实现的。编译器，而不是至少
一个主要玩家。
Well, stdint.h was only introduced in the 1999 standard, a standard that
is not fully implemented by many compilers and not at all by at least
one major player.
>如果我想要的话一个有符号整数，宽度至少为16，那么为什么选择int而不是int_fast16_t？ int_fast16_t是最快的有符号整数类型，其宽度至少为16，而int只是一个至少有16个宽度的有符号整数类型。似乎选择
int_fast16_t至少和选择int一样好。这个参数可以是N = 8,16,32,64，也可以是相应的无符号类型。
>If I want just a signed integer with at least 16 width, then why
choose int instead of int_fast16_t? int_fast16_t is the "fastest"
signed integer type that has at least 16 width, while int is simply a
signed integer type that has at least 16 width. It seems that choosing
int_fast16_t is at least as good as choosing int. This argument can be
made for N=8,16,32,64, and for the corresponding unsigned types.
是的，这是真的，也是使用它们的一个很好的理由。它确实限制了不支持这部分C99的实现的
可移植性，但是b $ b但是总是可以为
编写自己的stdint.h版本
这些系统。
Yes, this is true, and an excellent reason for using them. It does limit
portability to implementations that do not support this part of C99,
however it is always possible to write your own version of stdint.h for
those systems.
>< stdint.halso提供[u] int_leastN_t类型，这在<保持较小的存储容量是最大的问题。
><stdint.halso offers [u]int_leastN_t types, which are useful when
keeping a small storage size is the greatest concern.
是的。同样由于可能更小的尺寸，它们可以*更快*用于某些
目的。例如，如果较小的大小意味着所有内容都保存在
缓存中而不是必须被提取。
Yes. Also due to the possibly smaller size they can be *faster* for some
purposes. For example if the smaller size means everything is kept in
cache instead of having to be fetched.
>使用我可以看到的标准整数类型的唯一好处是它们的范围可能随着C标准的进展而扩展，因此
使用它们的代码可能会随着时间的推移而保持有用。
>The only benefit of using the standard integer types I can see is that
their ranges may expand as the C standard progresses, so code that
uses them might stay useful over time.
是的，这是一个潜在的优势。
Yes, that is a potential advantage.
>例如< stdio.h>的fseek
使用long作为其偏移参数，因此如果long的范围增长
那么fseek将自动提供更广泛的偏移量。
>For example fseek of <stdio.h>
uses a long for its offset parameter, so if the range of long grows
then fseek will automatically offer a wider range of offsets.
有一个论点，fseek应该使用另一种类型......
当然，那个这就是为什么有fsetpos。
There is an argument that fseek should have used another type...
Of course, that is why there is fsetpos.
>在Windows中注意（或者可能不是）它也很有趣世界上，长期存在于通用目的的想法已经被破坏了，而且长期已成为一种必须具有正好32位的类型。
>It''s also interesting to note (or maybe not) that in the Windows
world, the idea of long being general purpose has somewhat been
destroyed and long has become a type that must have exactly 32 bits.
是的，这不完全是MS的错。这是程序员，他们认为它总是正好是32位和/或假设它将是/ b $ b总是与int的大小相同。不打破这样的第三方代码，因为我理解它，是MS在Win64上长达32位的原因。
Yes, and it is not entirely the fault of MS. It is the programmers who
assumed that it would always be exactly 32 bits and/or assumed it would
always be the same size as int. Not breaking such 3rd party code, as I
understand it, was the reason for MS keeping long as 32 bits on Win64.
是，我们正在迅速走下破坏C基本整数
类型的道路。
Yes, we''re rapidly going down the path of destroying the C basic integer
types.
请注意，这个意见似乎对Malcolm来说几乎是独一无二的。
Malcolm不同意的很多部分是原始标准
发表于1989年，因此他对快速有一个非常奇怪的想法。
请注意，其他一些人认为固定宽度类型是错误的，
虽然我们中的一些人不同意，但双方都存在争议。更多
人们（我认为）会喜欢int32_t这样的快速
类型，并且对于可选的固定大小类型具有int_exact或int_fixed。
Note that this is an opinion that seems to be almost unique to Malcolm.
A lot of what Malcolm disagrees with was part of the original standard
published in 1989 so he has a very strange idea of "rapidly".
Note that some others think the fixed width types are a mistake,
although some of us disagree, there being arguments on both side. More
people (I think) would have liked things like int32_t being the fast
types and having int_exact or int_fixed for the optional fixed sized types.
一旦开始发明像int_fast16_t这样的类型，人们就会使用它们，
，语言变得越来越难读。
Once you start inventing types like int_fast16_t people will use them,
and the language becomes more and more difficult to read.
In * your * opinion。
In *your* opinion.
我自己认为你应该坚持字符的字符串
和整数的int，几乎在所有情况下。但是，如果你可以使用int作为任意数组索引和快速
类型，这只是
。
My own view is that you should be able to stick to char for characters
and int for integers, in almost every situation. However this is only
tenable if you can use int as both an arbitrary array index and a fast
type.
这不是它的目的，也不同意现代处理器的工作方式，因为32位整数通常会快于a 64
位整数（即使在64位硬件上）但是你需要一个64位整数来为
一个任意索引。类似的事情对于eariler HW来说是好的，因为
16/32位。所以Malcolm的观点是C必须同时满足两个相互矛盾的
要求。
-
Flash Gordon
Which is not its purpose and does not agree with the way modern
processors work since often a 32 bit integer will be faster than a 64
bit integer (even on 64 bit hardware) yet you need a 64 bit integer for
an arbitrary index. Similar things were true for eariler HW in terms of
16/32 bits. So Malcolm''s view is that C has to meet two contradictory
requirements at the same time.
--
Flash Gordon
" Malcolm McLean" < re ******* @ btinternet.com写了留言
新闻：pM *********************** ******* @ bt.com ...
"Malcolm McLean" <re*******@btinternet.comwrote in message
news:pM******************************@bt.com...
< eu ***** @ gmail.comwrote in message
<eu*****@gmail.comwrote in message
....
....
>它也很有趣（或者也许不是）在Windows
世界中，长期存在于通用目的的想法已经被破坏了，并且长期已成为一种必须具有正好32位的类型。
>It''s also interesting to note (or maybe not) that in the Windows
world, the idea of long being general purpose has somewhat been
destroyed and long has become a type that must have exactly 32 bits.
是的，我们正在快速走下破坏C基本整数
类型的道路。
一旦你开始发明类似于int_fast16_t的人会使用它们，并且
语言变得越来越难以阅读。
Yes, we''re rapidly going down the path of destroying the C basic integer
types.
Once you start inventing types like int_fast16_t people will use them, and
the language becomes more and more difficult to read.
>
我自己的观点是你应该能够坚持使用字符和字符来表示
几乎在所有情况下，
int表示整数。但是，如果你可以使用int作为任意数组索引和快速类型，那么这只是可行的
。
>
My own view is that you should be able to stick to char for characters and
int for integers, in almost every situation. However this is only tenable
if you can use int as both an arbitrary array index and a fast type.
我自己的看法恰恰相反。一个程序怎么能不知道一个''数据类型的比特值？b $ b？但是我可能花了太多时间进行低级别的b / b
编程。
我最近在clc中给出了一个long int数据类型的示例
32或64位，取决于编译器 - 在同一处理器上。因此，如果您将可信的便携式程序从一个编译器移植到另一个编译器，那么它可以更慢（或更快）地运行
。
无论如何，为了与其他（二进制）软件连接，
数据类型的确切大小变得很重要。或者（在我的情况下）试图从
另一种语言接口到C.
-
巴特
My own view is the opposite. How can one program without knowing the bitsize
of one''s datatypes? But I''ve probably spent too many years low-level
programming.
I gave one example in c.l.c recently of a long int datatype that was either
32 or 64-bits depending on compiler -- on the same processor. So if you port
a supposedly portable program from one compiler to another, it could run
much slower (or faster).
Anyway for interfacing with other (binary) software, the exact sizes of
datatypes becomes important. Or (in my case) trying to interface from
another language to C.
--
Bart
这篇关于标准整数类型vs< stdint.h>类型的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
