在做ACM题时,经常都会遇到一些比较大的整数。而常用的内置整数类型常常显得太小了:其中long 和 int 范围是[-2^31,2^31),即-2147483648~2147483647。而unsigned范围是[0,2^32),即0~4294967295。也就是说,常规的32位整数只能够处理40亿以下的数。
那遇到比40亿要大的数怎么办呢?这时就要用到C++的64位扩展了。不同的编译器对64位整数的扩展有所不同。基于ACM的需要,下面仅介绍VC6.0与g++编译器的扩展。 VC的64位整数分别叫做__int64与unsigned __int64,其范围分别是[-2^63, 2^63)与[0,2^64),即-9223372036854775808~9223372036854775807与0~18446744073709551615(约1800亿亿)。对64位整数的运算与32位整数基本相同,都支持四则运算与位运算等。当进行64位与32位的混合运算时,32位整数会被隐式转换成64位整数。但是,VC的输入输出与__int64的兼容就不是很好了,如果你写下这样一段代码:
1
__int64 a;
2cin>> a; 3cout<<a; 那么,在第2行会收到“error C2679: binary '>>' : no operator defined which takes a right-hand operand of type '__int64' (or there is no acceptable conversion)”的错误;在第3行会收到“error C2593: 'operator <<' is ambiguous”的错误。那是不是就不能进行输入输出呢?当然不是,你可以使用C的写法:
scanf("%I64d",&a);
printf("%I64d",a);
就可以正确输入输出了。当使用unsigned __int64时,把"I64d"改为"I64u"就可以了。
OJ通常使用g++编译器。其64位扩展方式与VC有所不同,它们分别叫做long long 与 unsigned long long。处理规模与除输入输出外的使用方法同上。对于输入输出,它的扩展比VC好。既可以使用
1
long long a;
2 cin>>a; 3 cout<<a;
也可以使用
scanf("%lld",&a);
printf("%lld",a); 使用无符号数时,将"%lld"改成"%llu"即可。 最后我补充一点:作为一个特例,如果你使用的是Dev-C++的g++编译器,它使用的是"%I64d"而非"%lld"。 |
zz from http://www.byvoid.com/blog/c-int64/ 在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位整型,我写了程序对它们进行了评测,结果如下表。
上表中,正确指编译通过,运行完全正确;错误指编译虽然通过,但运行结果有误;无法编译指编译器根本不能编译完成。观察上表,我们可以发现以下几点:
表中最后一行输出方式中的printint64()是我自己写的一个函数,可以看出,它的兼容性要好于其他所有的输出方式,它是一段这样的代码:
这种写法的本质是把较大的64位整型拆分为两个32位整型,然后依次输出,低位的部分要补0。看似很笨的写法,效果如何?我把它和cout输出方式做了比较,因为它和cout都是C++支持跨平台的。首先printint64()和cout(不清空缓冲区)的运行结果是完全相同的,不会出现错误。我的试验是分别用两者输出1000000个随机数,实际结果是,printint64()在1.5s内跑完了程序,而cout需要2s。cout要稍慢一些,所以在输出大量数据时,要尽量避免使用。 zz from http://blog.csdn.net/zhlynn/archive/2009/03/28/4032152.aspx 64位整数全解(增补板) 首先是如果我们在自己机器上写程序的话,情况分类如下: (1) 在win下的VC6.0里面,声明数据类型的时候应该写作 __int64 a; 输入输出的时候用 %I64d scanf(”%I64d”,&a); (2) 在linux下的gcc/g++里面,数据类型声明写作 long long a; 输入输出时候用 %lld (3) 在win下的其它IDE里面[包括高版本Visual Studio],数据类型声明用上面两种均可 输入输出用 %I64d ================== 以下可无视 ========================= 以下是对这种混乱情况的解释,如无兴趣可以跳过 首先要说的是,和Java等语言不同,C/C++本身并没有规定各数据类型的位数,只 是限定了一个大小关系,也就是规定从所占的bit数来说,short <= int <= long <= long long。至于具体哪种类型占用多少位,是由你所用的开发平台的编译器决定的。在现在的PC上一个通常的标准是,int和long同为32位,long long为64位。但是如果换到其它平台(如ARM)上,这个数字可能会有不同,类型所占的大小可以用sizeof()运算符查看。 long long是C99标准中新引进的数据类型,在古老的VC6.0中并没有这个类型,所以在VC6.0中用”long long”会发生编译错误。为了表示64位整数,VC6里采用的是微软自己搞出来的一个数据类型,叫做__int64,所以如果你是在VC6.0下编译的 话,应该用__int64定义64位整型。新版的Visual Studio已经支持long long了。GCC是支持long long的,我们在win系统中使用的其它IDE如Dev-Cpp, Code::Blocks等等大多是采用的MinGW编译环境,它是与GCC兼容的,所以也支持long long(另外为了与MS兼容,也支持__int64)。如果是在纯的linux下,就只能使用long long了。 关于使用printf的输入输出,这里就有一个更囧的情况。实际上只要记住,主要的区 分在于操作系统:如果在win系统下,那么无论什么编译器,一律用%I64d;如果在linux系统,一律用%lld。这是因为MS提供的 msvcrt.dll库里使用的就是%I64d的方式,尽管Dev-Cpp等在语法上支持标准,但也不得不使用MS提供的dll库来完成IO,所以就造成 了这种情况。 ==================== 无视至此 =========================== 那么对ACMer来说,最为关心的就是在各个OJ上交题应分别使用哪种方式了。其实方式只有有限的几种: 如果服务器是linux系统,那么定义用long long,IO用%lld 下面把各大OJ情况列表如下: 1. TOJ : Linux系统 如果有不太清楚的情况可以先看看各OJ上的FAQ,通常会有说明。 另外,为了避免混乱,当数据量不大时,用cin, cout进行输入输出也是一种选择 |