选择最合适的整数大小/范围用于变量
C99 中的 stdint.h 提供了许多整数大小、类型的选项和范围 - 太多了我不知道该选择什么！
我知道如何在适当的时候使用size_t和ptrdiff_t，我使用固定大小类型进行存储和传输。我的问题涉及仅存储在主机内存中的值。
例如，图像的结构可能包含以下成员：
struct image {
integer width, height; /* pixel dimensions of the image */
integer bits_per_pixel;
...
};
如果 width 和 height 永远不会超过 SHRT_MAX，则应该 short<使用 /code>，还是坚持使用 int？图像的宽度或高度不能为负，因此使用无符号类型？也许 (u)int_least16_t 是正确的选择？还有别的事吗？
如果 bits_per_pixel 永远不会超过值 64，请使用 char、unsigned char、uint8_t、int< /代码> 还是其他什么？
在这个例子中你会使用什么以及为什么？
运行代码的 CPU 架构如何影响选择？即 PPC 或 x86、32 或 64 位。
运行代码的设备如何影响选择？即桌面、电话、控制台。
该选择与性能和优化有何关系？
简而言之，我的问题是：如何选择使用哪个整数？
stdint.h in C99 provides many options for integer sizes, types and ranges - so many I don't know what ones to choose!
I know how to use size_t and ptrdiff_t when appropriate, and I use fixed size types for storage and transmission. My question concerns values that will only be stored in memory of the host machine.
For example, a structure for an image might contain these members:
struct image {
integer width, height; /* pixel dimensions of the image */
integer bits_per_pixel;
...
};
If width and height will never exceed SHRT_MAX, should a short be used, or stick with int? An image can't have negative width or height, so use an unsigned type? Perhaps (u)int_least16_t is the correct choice? Something else?
If bits_per_pixel will never exceed a value of 64 use char, unsigned char, uint8_t, int or something else?
What would you use in this example and why?
How does the CPU architecture the code will run on affect the choice? i.e. PPC or x86, 32 or 64bit.
How does the device the code will run on affect the choice? i.e. Desktop, phone, console.
How does the choice relate to performance and optimization?
My question in simple terms is: How do you choose which integer to use?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我想说：不要太担心这个，它通常是一种过早优化的形式。但我的经验法则是：
int。它应该是机器的自然字大小。(u)intX_t类型。<= UCHAR_MAX的大型数组，请使用unsigned char。请注意，
I would say: Don't worry to much about this, it often is a form of premature optimisation. But my rules of thumb are:
intwhen possible. It should be the natural word size of the machine.unsignedtypes when you need well-defined integer overflow.(u)intX_ttype when you need two's-complement representation.unsigned charfor large arrays with values<= UCHAR_MAX.Beware that a lot of the types in
<stdint.h>are optional, so you can't depend on their existence. POSIX makes this slightly better.对于您的示例，我将简单地对所有三个字段使用
int或（也许更好）unsigned。除了包含数千或数百万个元素的数组之外，使用较小的类型是没有意义的；它只是强加了人为的限制。为了回答更普遍的问题，我遵循以下一些指导原则：
size_t。stdint.h（uint8_t、uint16_t、uint32_t等）。此类需求的常见示例包括像素值、音频样本和 Unicode 字符（通常分别为 8 位、16 位和 32 位）。int或unsigned可能是正确的类型。For your example, I would simply use
intor (perhaps better)unsignedfor all three fields. There is no sense using smaller types except in an array that will contain thousands or millions of elements; it just imposes artificial limits.To answer the more general question, here are some guidelines I go by:
size_t.stdint.h(uint8_t,uint16_t,uint32_t, etc.). The common examples of this sort of need that come to mind are pixel values, audio samples, and Unicode characters (typically 8, 16, and 32 bit, respectively).intorunsignedis probably the right type to use.没有硬性规定。
如果您选择的类型太小，您最终可能会人为地限制程序可以处理的数据集。太大，您的性能可能会受到影响。
除非您在特定任务中遇到性能问题，否则我肯定会倾向于“太大”。虽然使用整数表示位/像素有点愚蠢，但它可能不会损害更大的方案中的任何内容。
There are no hard and fast rules.
If you choose a type too small, you can end up artificially limiting the data sets that your program can handle. Too big, and your performance may suffer.
Unless you are running in to performance problems for your specific task, I would definitely lean towards "too big". While using an integer for bits/pixel is kind of silly, it probably wont hurt anything in the greater scheme of things.
除非您的应用程序确实占用大量内存，否则不要担心大小并使用 int。使用 Short 或 char 可能会导致细微的错误，这些错误可能会在以后引起问题。此外，使用 char 或 Short 不会获得任何额外的 CPU 周期。
Unless your application is really memory intensive, don't worry about sizes and use int. Using short or char can cause subtle bugs which may cause problems later. Also, using char or short won't gain you any additional CPU cycles.