数据类型

数据类型特别是int相关的类型在不同位数机器的平台下长度不同。C99标准并不规定具体数据类型的长度大小，只规定级别。作下比较：

16位平台

char         1个字节8位
short        2个字节16位
int            2个字节16位
long         4个字节32位
指针         2个字节

32位平台

char         1个字节8位
short        2个字节16位
int            4个字节32位
long         4个字节
long long 8个字节
指针         4个字节

64位平台

char         1个字节
short        2个字节
int            4个字节
long         8个字节（区别）
long long 8个字节
指针        8个字节（区别）

固定大小的数据类型

为了保证平台的通用性，程序中尽量不要使用long数据库型。可以使用固定大小的数据类型宏定义：

typedef signed char       int8_t

typedef short int         int16_t;

typedef int               int32_t;

# if __WORDSIZE == 64
typedef long int          int64_t;
# else
__extension__
typedef long long int     int64_t;

#endif

使用int时也可以使用intptr_t来保证平台的通用性，它在不同的平台上编译时长度不同，但都是标准的平台长度，比如64位机器它的长度就是8字节，32位机器它的长度是4字节，定义如下：

1
2
3
4
5

#if __WORDSIZE == 64
typedef long int                intptr_t;
#else
typedef int                        intptr_t;
#endif

编程中要尽量使用sizeof来计算数据类型的大小

以上类型定义都有相应的无符号类型。

另外还有ssize_t和size_t分别是sign size_t和unsigned signed size of computer word size。它们也是表示计算机的字长，在32位机器上是int型，在64位机器上long型，从某种意义上来说它们等同于intptr_t和 uintptr_t。它们在stddef.h里面定义。需要注意的是socket的accept函数在有些操作系统上使用size_t是不正确的，因为 accept接收的int*类型，而size_t可能是long int 类型。后来BSD使用sock_t来替代它。

C/C++的64位整型

在C/C++中，64为整型一直是一种没有确定规范的数据类型。现今主流的编译器中，对64为整型的支持也是标准不一，形态各异。一般来说，64位整型的定义方式有long long和__int64两种(VC还支持_int64)，而输出到标准输出方式有printf(“%lld”,a)，printf(“%I64d”,a)，和cout « a三种方式。

本文讨论的是五种常用的C/C++编译器对64位整型的支持，这五种编译器分别是gcc(mingw32)，g++(mingw32)，gcc(Linux i386)，g++(linux i386)，Microsoft Visual C++ 6.0。可惜的是，没有一种定义和输出方式组合，同时兼容这五种编译器。为彻底弄清不同编译器对64位整型，我写了程序对它们进行了评测，结果如下表。

上表中，正确指编译通过，运行完全正确；错误指编译虽然通过，但运行结果有误；无法编译指编译器根本不能编译完成。观察上表，我们可以发现以下几点：

long long定义方式可以用于gcc/g++，不受平台限制，但不能用于VC6.0。

__int64是Win32平台编译器64位长整型的定义方式，不能用于Linux。

“%lld”用于Linux i386平台编译器，”%I64d”用于Win32平台编译器。

cout只能用于C++编译，在VC6.0中，cout不支持64位长整型。

如果服务器是linux系统，那么定义用long long，IO用%lld 如果服务器是win系统，那么声明要针对编译器而定：

  1. 如果用MS系列编译器，声明用__int64 [现在新版的Visual Studio也支持long long了]

  2. 如果用MinGW环境，声明用long long

  3. 无论什么编译器，IO一律%I64d

参考：http://blog.csdn.net/hongxdong/article/details/5559312