我正在寻找有关基本C++类型大小的详细信息.我知道这取决于架构(16位,32位,64位)和编译器.
但是有没有C++的标准？
我在32位架构上使用Visual Studio 2008.这是我得到的:
char : 1 byte
short : 2 bytes
int : 4 bytes
long : 4 bytes
float : 4 bytes
double: 8 bytes
我试图找到,但没有成功,可靠的信息,表述的大小char,short,int,long,double,float(和其他类型的我没想到的),在不同的体系结构和编译器.
是否有标准投诉方法来表示ANSI(C89/90)C中的字节？我知道,大多数情况下,一个字符恰好是一个字节,但我的理解是,这不能保证是这种情况.另外,在C99标准中有stdint.h,但在C99之前使用了什么？
我特别想知道8位和"字节"(sizeof(x)== 1).
我正在尝试创建一个C源代码,无论目标系统的字节顺序如何,它都能正确处理I/O.
我选择了"little endian"作为我的I/O约定,这意味着,对于大端CPU,我需要在写入或读取时转换数据.
转换不是问题.我面临的问题是检测字节序,最好是在编译时(因为CPU在执行过程中不会改变字节序...).
到目前为止,我一直在使用这个:
#if __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__
...
#else
...
#endif
它被记录为GCC预定义的宏,而Visual似乎也理解它.
但是,我收到报告说某些big_endian系统(PowerPC)的检查失败了.
所以,我正在寻找一个万无一失的解决方案,确保无论编译器和目标系统如何都能正确检测到字节顺序.好吧,他们中的大多数至少......
[编辑]:提出的大多数解决方案都依赖于"运行时测试".编译期间编译器有时可以正确评估这些测试,因此不会产生实际的运行时性能.
然而,用某种<< if (0) { ... } else { ... }>> 分支是不够的.在当前的代码实现中,变量和函数声明依赖于big_endian检测.使用if语句无法更改这些内容.
嗯,显然,有后备计划,即重写代码......
我宁愿避免这种情况,但是,它看起来像是一个越来越少的希望......
[编辑2]:我通过深度修改代码测试了"运行时测试".尽管他们正确地完成了工作,但这些测试也会影响性能.
我期待着,因为测试具有可预测的输出,编译器可以消除坏分支.但不幸的是,它并不是一直有效.MSVC是一个很好的编译器,并且成功地消除了坏分支,但是GCC的结果是混合的,这取决于版本,测试类型,以及对64位比对32位的影响更大.
真奇怪.而且这也意味着无法确保编译器处理运行时测试.
编辑3:这些天,我正在使用编译时常量联合,期望编译器将其解析为明确的是/否信号.它运作得很好:https: //godbolt.org/g/DAafKo