//为了和DSP兼容,TSint64和TUint64设置成TSint40和TUint40一样的数

//结果VC中还是认为是32位的,显然不合适

//typedef signed long int     TSint64;

//typedef unsigned long int   TUint64;

//ANSI C中规定long long才能表示64位

//参见:http://msdn.microsoft.com/en-us/library/s3f49ktz.aspx

//可惜VC++ 6.0 不认识 long long,会报error C2632: 'long' followed by 'long' is illegal

typedef signed long long     TSint64;//It's illegal in C90. It's legel in C99.

typedef unsigned long long   TUint64;

//typedef LONGLONG    TSint64;//VC不认

//typedef ULONGLONG   TUint64;

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位整型,我写了程序对它们进行了评测,结果如下表。

变量定义 输出方式 gcc(mingw32) g++(mingw32) gcc(linux i386) g++(linux i386) MicrosoftVisual C++ 6.0
long long “%lld” 错误 错误 正确 正确 无法编译
long long “%I64d” 正确 正确 错误 错误 无法编译
__int64 “lld” 错误 错误 无法编译 无法编译 错误
__int64 “%I64d” 正确 正确 无法编译 无法编译 正确
long long cout 非C++ 正确 非C++ 正确 无法编译
__int64 cout 非C++ 正确 非C++ 无法编译 无法编译
long long printint64() 正确 正确 正确 正确 无法编译

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

  1. long long定义方式可以用于gcc/g++,不受平台限制,但不能用于VC6.0。
  2. __int64是Win32平台编译器64位长整型的定义方式,不能用于Linux。
  3. “%lld”用于Linux i386平台编译器,”%I64d”用于Win32平台编译器。
  4. cout只能用于C++编译,在VC6.0中,cout不支持64位长整型。

表中最后一行输出方式中的printint64()是我自己写的一个函数,可以看出,它的兼容性要好于其他所有的输出方式,它是一段这样的代码:

  1. void printint64(long long a)
  2. {
  3. if (a<=100000000)
  4. printf("%d/n",a);
  5. else
  6. {
  7. printf("%d",a/100000000);
  8. printf("%08d/n",a%100000000);
  9. }
  10. }

这种写法的本质是把较大的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位整数全解(增补板) 
  
64位整形引起的混乱主要在两方面,一是数据类型的声明,二是输入输出。

首先是如果我们在自己机器上写程序的话,情况分类如下:

(1) 在win下的VC6.0里面,声明数据类型的时候应该写作

__int64 a;

输入输出的时候用 %I64d

scanf(”%I64d”,&a);
printf(”%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
如果服务器是win系统,那么声明要针对编译器而定:
+ 如果用MS系列编译器,声明用__int64 [现在新版的Visual Studio也支持long long了]
+ 如果用MinGW环境,声明用long long
+ 无论什么编译器,IO一律%I64d

下面把各大OJ情况列表如下:

1. TOJ : Linux系统
2. ZOJ : Linux系统
3. POJ : Win系统,语言如选择C/C++,则用MS编译器[支持两种声明],如选择GCC/G++,则为MinGW
4. UVa : Linux系统
5. Ural: Win系统,MS编译器[支持两种声明]
6. SPOJ: Linux系统
7. SGU : Win系统,MS编译器[支持两种声明]

如果有不太清楚的情况可以先看看各OJ上的FAQ,通常会有说明。

另外,为了避免混乱,当数据量不大时,用cin, cout进行输入输出也是一种选择

  1. //为了和DSP兼容,TSint64和TUint64设置成TSint40和TUint40一样的数
  2. //结果VC中还是认为是32位的,显然不合适
  3. //typedef signed long int     TSint64;
  4. //typedef unsigned long int   TUint64;
  5. //ANSI C中规定long long才能表示64位
  6. //参见:http://msdn.microsoft.com/en-us/library/s3f49ktz.aspx
  7. //可惜VC++ 6.0 不认识 long long,会报error C2632: 'long' followed by 'long' is illegal
  8. typedef signed long long     TSint64;//It's illegal in C90. It's legel in C99.
  9. typedef unsigned long long   TUint64;
  10. //typedef LONGLONG    TSint64;//VC不认
  11. //typedef ULONGLONG   TUint64;

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位整型,我写了程序对它们进行了评测,结果如下表。

变量定义 输出方式 gcc(mingw32) g++(mingw32) gcc(linux i386) g++(linux i386) MicrosoftVisual C++ 6.0
long long “%lld” 错误 错误 正确 正确 无法编译
long long “%I64d” 正确 正确 错误 错误 无法编译
__int64 “lld” 错误 错误 无法编译 无法编译 错误
__int64 “%I64d” 正确 正确 无法编译 无法编译 正确
long long cout 非C++ 正确 非C++ 正确 无法编译
__int64 cout 非C++ 正确 非C++ 无法编译 无法编译
long long printint64() 正确 正确 正确 正确 无法编译

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

  1. long long定义方式可以用于gcc/g++,不受平台限制,但不能用于VC6.0。
  2. __int64是Win32平台编译器64位长整型的定义方式,不能用于Linux。
  3. “%lld”用于Linux i386平台编译器,”%I64d”用于Win32平台编译器。
  4. cout只能用于C++编译,在VC6.0中,cout不支持64位长整型。

表中最后一行输出方式中的printint64()是我自己写的一个函数,可以看出,它的兼容性要好于其他所有的输出方式,它是一段这样的代码:

  1. void printint64(long long a)
  2. {
  3. if (a<=100000000)
  4. printf("%d/n",a);
  5. else
  6. {
  7. printf("%d",a/100000000);
  8. printf("%08d/n",a%100000000);
  9. }
  10. }

这种写法的本质是把较大的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位整数全解(增补板) 
  
64位整形引起的混乱主要在两方面,一是数据类型的声明,二是输入输出。

首先是如果我们在自己机器上写程序的话,情况分类如下:

(1) 在win下的VC6.0里面,声明数据类型的时候应该写作

__int64 a;

输入输出的时候用 %I64d

scanf(”%I64d”,&a);
printf(”%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
如果服务器是win系统,那么声明要针对编译器而定:
+ 如果用MS系列编译器,声明用__int64 [现在新版的Visual Studio也支持long long了]
+ 如果用MinGW环境,声明用long long
+ 无论什么编译器,IO一律%I64d

下面把各大OJ情况列表如下:

1. TOJ : Linux系统
2. ZOJ : Linux系统
3. POJ : Win系统,语言如选择C/C++,则用MS编译器[支持两种声明],如选择GCC/G++,则为MinGW
4. UVa : Linux系统
5. Ural: Win系统,MS编译器[支持两种声明]
6. SPOJ: Linux系统
7. SGU : Win系统,MS编译器[支持两种声明]

如果有不太清楚的情况可以先看看各OJ上的FAQ,通常会有说明。

另外,为了避免混乱,当数据量不大时,用cin, cout进行输入输出也是一种选择

%I64d 和%lld 的区别相关推荐

  1. 2022- 7 - 8做题时忽略的知识

    transform函数 C++中有两个函数可进行快速变换大小写,tolower()函数是把字符串都转化为小写字母:toupper()函数是把字符串都转化为大写字母.故上述代码中transform函数可 ...

  2. SCAU 9502 ARDF

    9502 ARDF 时间限制:1000MS  内存限制:65535K 提交次数:0 通过次数:0 题型: 编程题   语言: 无限制 Description ARDF,全称无线电测向.无线电测向运动是 ...

  3. linux添加美式键盘,win8\win server 2012添加【中文--美式键盘】

    关于div的居中的问题 (从已经死了一次又一次终于挂掉的百度空间人工抢救出来的,发表日期2014-01-11) div水平和垂直居中,text-align和vertical-align不起作用,因为标 ...

  4. POJ-排序-归并排序与逆序对

    排序:归并排序与逆序对 一.概念 归并排序(MERGE-SORT)是建立在归并操作上的一种有效的排序算法,该算法是采用分治法(Divide and Conquer)的一个非常典型的应用.将已有序的子序 ...

  5. P2344 奶牛抗议

    P2344 奶牛抗议 题目背景 Generic Cow Protests, 2011 Feb 题目描述 约翰家的N 头奶牛正在排队游行抗议.一些奶牛情绪激动,约翰测算下来,排在第i 位的奶牛的理智度为 ...

  6. 2016CCPC合肥赛区总结

    时间过得真快,不知不觉一个赛区就打完了,距离刚接触ACM也快一年了,这一年的收获真的非常大,万 分感谢我的老师和一起努力的朋友们. ---------------------------------- ...

  7. 一道题Wrong Answer之后该何去何从?

    敲代码手不稳是个大毛病,往往会让一份能AC的代码变成99.995%正确,失之毫厘谬以千里,最近十场个人赛很少有能一次AC的经历,仔细想想除了根本逻辑上的错误,大概都是跪在这些细节上: 1.输出格式,输 ...

  8. 3131: [Sdoi2013]淘金

    传送门:http://www.lydsy.com/JudgeOnline/problem.php?id=3131 思路:人生第一道数位dp,,,解锁了人生新成就,,, 数位dp的一般思路,分为两步:1 ...

  9. 好学易懂 从零开始的插头DP(三)

    好学易懂 从零开始的插头DP(三) 写在前面 这篇文章主要是介绍一些括号表示法和简单回路的基本变化,下一篇会是一些非回路(最小表示),毒瘤状态(正wa着所以咕着),结合矩阵乘法加速等一些复杂应用.下下 ...

最新文章

  1. 前端面试常考知识点---js
  2. 转 layer的Icon样式以及一些常用的layer窗口使用
  3. leetcode之Valid Sudoku有效的数独(一步步改进代码)
  4. 【职场经验】算法同学从学校到实习,需要改变什么
  5. c# DirectoryInfo 类和 FileInfo 类
  6. web.config连接mysql_web.config中配置数据库连接的方式
  7. 警示!国基金评审过程“打招呼”被通报批评,撤销已资助项目!
  8. ORACLE中date类型字段的处理
  9. 统一代码格式 in UltraEdit
  10. Linux驱动(8)--内核编译与配置
  11. awk 第一个文件的数字乘以第二个文件的数字
  12. fprom预测结果内容_生物标志物联合OCT预测ACS患者再发冠脉事件|博“冠”精点...
  13. 数据库删除表中多列语法总结
  14. RIME输入法配置双拼方案(Ubuntu下基于ibus)
  15. 怎样在Word添加页码?经验干货!word如何插入页码?
  16. C/C++读取txt
  17. MySQL数据库操作与查询的综合测试题
  18. java 接口重写_java如何实现接口中的重写
  19. 浮动广告代码在网页两侧
  20. 用计算机语法表示谁在说谎,2019考研管理类联考逻辑思维训练题:假设法(2)

热门文章

  1. led-led paths_LED时刻的重要性-我做到了
  2. ps 选区工具的使用
  3. 获取sku详细信息 API 返回值说明
  4. FMDB-FMDatabaseQueue
  5. libuv访问mysql_libuv中的QUEUE
  6. NKOI 1349 工作安排
  7. 没有学历的程序员上限很低吗?BATZ面试评分最高的我,因为学历止步大厂......
  8. 在东北老家坐长途车的遭遇
  9. 某985学历程序员嫌弃女朋友高职毕业学历低,但女朋友实在太漂亮,好犹豫!...
  10. Linux查询一个进程是被那个启动项启动的