为什么在stdint.h中有最小和快速整数类型? [英] Why in stdint.h have both least and fast integer types?

查看:106
本文介绍了为什么在stdint.h中有最小和快速整数类型?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

stdint.h标头定义提到五个整数类别,


1)确切的宽度,例如,int32_t

2)至少与,例如,int_least32_t

3)尽可能快,但至少与例如int_fast32_t一样宽,
4)能够持有指针的整数,intptr_t

5)实现中最宽的整数,intmax_t


是否有同时拥有int_least和int_fast的有效动机?


-

TIA

解决方案

文章< 79 ************ **************@posting.google.com>,
gr ************ @ yahoo.co.uk (GS)写道:

stdint.h header定义提到五个整数类别,1)确切的宽度,例如,int32_t
2)至少与尽可能宽,例如,int_least32_t
3)尽可能快但是至少与例如int_fast32_t一样宽,4)整数能力持有指针,intptr_t
5)实现中最宽的整数,intmax_t

是否有同时拥有int_least和int_fast的有效动机?



当然。如果你的硬件中16位整数很慢,并且32位

int_fast16_t为32位。这涵盖了你可以在商店购买的每台电脑。




" Christian Bau" < CH *********** @ cbau.freeserve.co.uk>在消息中写道

news:ch ********************************* @ slb- newsm1.svr.pol.co.uk ...

文章< 79 ************************* *@posting.google.com>,
gr ******* *****@yahoo.co.uk (GS)写道:

stdint.h标题定义提到五个整数类别,
1)确切的宽度,例如,int32_t
2)至少与例如int_least32_t
3)一样宽,尽可能快,但至少与例如int_fast32_t
4)整数能够持有指针,intptr_t
5)实现中最宽的整数,intmax_t

是否有同时拥有int_least和int_fast的有效动机?



当然。如果你的硬件中16位整数很慢,并且32位整数很快,那么你希望int_least16_t为16位,并且int_fast16_t为32位。这涵盖了你可以在商店购买的每台电脑。




有趣的例子但是int_least16_t真的有什么优势呢?如果

我们正在谈论一些标量,那么让编译器

将它们表示为int32s是不行的,因为它们更快?另一方面,如果
这些存储在数组中

int_least16_t fred [10000];

为什么不让编译器选择是否存储为int16或int32,

取决于它的优化限制?


-

James


>>> stdint.h头文件定义提到五个整数类别,


1)确切的宽度,例如,int32_t
2)至少与例如int_least32_t
3)一样宽,尽可能快,但至少与例如int_fast32_t一样宽,4)能够保持指针的整数,intptr_t < 5)实现中最宽的整数,intmax_t

是否有同时拥有int_least和int_fast的有效动机?
当然。如果你的硬件中16位整数很慢,并且32位整数很快,那么你希望int_least16_t为16位,并且int_fast16_t为32位。这涵盖了你可以在商店购买的每台电脑。



有趣的例子但int_least16_t真正给出了什么优势?如果




节省空间。

我们谈论的几个标量就不会让编译器好了
将它们表示为int32s,因为它们更快?


程序员使用int_least16_t超过int_fast16_t要求使用

来节省内存。如果程序不适合(虚拟)内存,速度并不是很好。




少数标量可能是故意制作的与另一个编译单元中使用的大数组(或磁盘文件)的
类型相同。

一个例子是使用第三方将数据存储在dbm文件中

库。当你从dbm文件中检索数据时,你会得到一个指向数据的

指针,但看起来它通常很简单地对齐,并且无论如何都是dbm函数不保证对齐,

因此使用它的方法是将memcpy()转换为

相同类型的变量/结构,并在那里访问它。如果不同的编译

对于int_least16_t有不同的大小,则会失败。

如果,另一方面,这些存储在数组中
int_least16_t fred [ 10000];
为什么不让编译器选择是存储为int16还是int32,
取决于它的优化约束?




sizeof(int_least16_t)在所有编译单元中必须相同

才能链接在一起以制作程序。 (当然,数组

下标,分配一个变量或int_least16_t数组,并且

指针递增所有隐式使用该大小)优化器



仅引用它时,没有太多关于int_least16_t大小的信息:


void * vp;

size_t record_count;


qsort(vp,record_count,sizeof(int_least16_t),compar);


但是,使用该信息,编译器*必须*现在选择。

也许在实际分配数组vp点之前的部分

at甚至是写的。


Gordon L. Burditt


The stdint.h header definition mentions five integer categories,

1) exact width, eg., int32_t
2) at least as wide as, eg., int_least32_t
3) as fast as possible but at least as wide as, eg., int_fast32_t
4) integer capable of holding a pointer, intptr_t
5) widest integer in the implementation, intmax_t

Is there a valid motivation for having both int_least and int_fast?

--
TIA

解决方案

In article <79**************************@posting.google.com >,
gr************@yahoo.co.uk (GS) wrote:

The stdint.h header definition mentions five integer categories,

1) exact width, eg., int32_t
2) at least as wide as, eg., int_least32_t
3) as fast as possible but at least as wide as, eg., int_fast32_t
4) integer capable of holding a pointer, intptr_t
5) widest integer in the implementation, intmax_t

Is there a valid motivation for having both int_least and int_fast?



Of course. If 16 bit integers are slow in your hardware, and 32 bit
integers are fast, then you would want int_least16_t to be 16 bit, and
int_fast16_t to be 32 bit. That covers about every computer that you can
buy in a shop.



"Christian Bau" <ch***********@cbau.freeserve.co.uk> wrote in message
news:ch*********************************@slb-newsm1.svr.pol.co.uk...

In article <79**************************@posting.google.com >,
gr************@yahoo.co.uk (GS) wrote:

The stdint.h header definition mentions five integer categories,

1) exact width, eg., int32_t
2) at least as wide as, eg., int_least32_t
3) as fast as possible but at least as wide as, eg., int_fast32_t
4) integer capable of holding a pointer, intptr_t
5) widest integer in the implementation, intmax_t

Is there a valid motivation for having both int_least and int_fast?



Of course. If 16 bit integers are slow in your hardware, and 32 bit
integers are fast, then you would want int_least16_t to be 16 bit, and
int_fast16_t to be 32 bit. That covers about every computer that you can
buy in a shop.



Interesting example but what advantage does int_least16_t really give? If
we are talking about a few scalars wouldn''t it be OK to let the compiler
represent them as int32s since they are faster? If, on the other hand,
these were stored in arrays
int_least16_t fred [10000];
why not let the compiler choose whether to store as int16 or int32,
depending on it''s optimization constraints?

--
James


>>> The stdint.h header definition mentions five integer categories,


1) exact width, eg., int32_t
2) at least as wide as, eg., int_least32_t
3) as fast as possible but at least as wide as, eg., int_fast32_t
4) integer capable of holding a pointer, intptr_t
5) widest integer in the implementation, intmax_t

Is there a valid motivation for having both int_least and int_fast?
Of course. If 16 bit integers are slow in your hardware, and 32 bit
integers are fast, then you would want int_least16_t to be 16 bit, and
int_fast16_t to be 32 bit. That covers about every computer that you can
buy in a shop.



Interesting example but what advantage does int_least16_t really give? If



Space savings.
we are talking about a few scalars wouldn''t it be OK to let the compiler
represent them as int32s since they are faster?
The programmer asked for memory savings over speed savings by
using int_least16_t over int_fast16_t. Speed doesn''t do much good
if the program won''t fit in (virtual) memory.

The few scalars might be deliberately made the same type as that
of a big array (or disk file) used in another compilation unit.
One example of this is storing data in dbm files using a third-party
library. When you retrieve data from dbm files, you get back a
pointer to the data, but it seems like it''s usually pessimally
aligned, and in any case the dbm functions do not guarantee alignment,
so the way to use it is to memcpy() to a variable/structure of the
same type, and access it there. This fails if different compilations
have different sizes for int_least16_t.
If, on the other hand,
these were stored in arrays
int_least16_t fred [10000];
why not let the compiler choose whether to store as int16 or int32,
depending on it''s optimization constraints?



sizeof(int_least16_t) must be the same in all compilation units
that get linked together to make a program. (of course, array
subscripting, allocating a variable or array of int_least16_t, and
pointer incrementing all implicitly use that size) The optimizer
doesn''t get much info on what size to make int_least16_t when the
only reference to it is:

void *vp;
size_t record_count;

qsort(vp, record_count, sizeof(int_least16_t), compar);

However, using that information, the compiler *MUST* choose now.
Perhaps before the part that actually allocates the array vp points
at is even written.

Gordon L. Burditt


这篇关于为什么在stdint.h中有最小和快速整数类型?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆