前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >EasyC++05,C++中的long long和__int64

EasyC++05,C++中的long long和__int64

作者头像
TechFlow-承志
发布2022-08-26 16:33:29
6990
发布2022-08-26 16:33:29
举报
文章被收录于专栏:TechFlow

作者 | 梁唐

大家好,我是梁唐。

这是EasyC++系列第五篇,聊聊C++中long long__int64

long long 和 __int64

在C++ Primer当中提到的64位的int只有long long,但是在实际各种各样的C++编译器当中,64位的int一直有两种标准。一种是long long,还有一种是__int64,非主流的VC甚至还支持_int64

对于一般的C++开发者来说,其实这个问题不那么要紧,因为在实际开发当中,绝大多数情况使用32位的int就足够应付了。很少会出现超过int范围的情况,但是对于算法玩家来说,这是一个必须考量的问题。因为很多题目会故意把范围弄得很大,考察选手对于数据范围的敏感。

关于long long__int64,我们有非常多的问题要讨论,我们一个一个来说。

历史遗留问题

首先是聊聊这个问题的背景,为什么会有两种标准呢?这并不是C++的标准不严谨,或者是各大编译器乱来,背后是有一个历史遗留问题的。

long long最早是C99标准引进的,然而VC6.0推出于1998年,在C99标准之前。所以当时微软就自己搞出来一个变量叫做__int64来表示64位整数。很多同学使用的第一个C++的编译器就是VC6.0,所以记得在VC6.0当中要使用__int64而非long long

既然VC6.0搞出了__int64,那么微软后续的C++版本显然就必须要兼容它。所以在win系统当中,这个__int64的变量类型就一直沿用了下来。当然,由于C++标准的更新,当然最新的visual studio已经支持long long了。

GCC并不是基于windows系统的,自然支持long long。win平台下的一些其他IDE如dev C++,CodeBlocks等也支持long long,因为它们为了和微软的系统兼容,所以也支持__int64。所以一个比较简单的区分方法是,判断编译器运行的操作系统是否是windows,如果是windows使用__int64,否则使用long long

cin、cout和scanf、printf的选择问题

这个问题对于C++开发工程师来说同样不是个问题,没有任何选择的必要,无脑用cin、cout就完事了。但对于算法竞赛玩家来说,这依然是一个要考虑的问题。

因为在算法竞赛当中,尤其是当数据量很大的时候,读入和输出占据的时间是非常可观的。看起来只是cin coutscanfprintf的差别,但是两者的性能差异非常大。

我曾经做过实验,同样的数据,使用scanfprintf的效率大约是cincout的十倍以上。在小数据量的时候当然没有差别,但数据量很大的时候影响非常大。很有可能导致同样的题目,同样的算法,别人通过了,但是我们却超时了的情况。

关于性能差异的原因,主要有两种解释。一种解释是说cin为了与scanf混用,而不用担心指针混乱,加上了绑定,总是会与stdin保持同步。正是这一步操作消耗了大量的时间。同理,cout也会有类似的问题。第二种解释是cout在输出之前会把要输出的内容先存入缓存区,中间多了一个步骤,也会带来性能的降低。

关于cin与stdin同步带来的开销,我们是有办法解决的,只需要在加上这一行代码:

代码语言:javascript
复制
std::ios::sync_with_stdio(false);

这行代码的意思是取消cincoutstdinstdout的指针同步,会使得cin、cout的性能大大提升,达到和scanfprintf相差无几的程度。当然,更好的方法是使用scanfprintf代替。

而要使用scanfprintf又有一个问题,它们是C语言的标准输入输出方式,需要提供标识符来代表变量的类型,那么问题来了long long__int64的标识符是什么呢?

这个其实一查就知道了,long long的标识符是lld,所以我们使用scanf读入一个long long类型的数写成:

代码语言:javascript
复制
long long a;
scanf("%lld", &a);

__int64的标识符是I64d,注意这里是大写的i,不是l。

代码语言:javascript
复制
__int64 a;
scanf("%I64d", &a);

但是这里面有一个很大的坑点,前面说了,目前在windows平台的编译器已经兼容了long long类型。但是即便如此,在2013年之前的版本里,我们输出的时候还是要使用%I64d,这是因为微软提供的msvcrt.dll库只支持%I64d的方式。相当于从底层上断绝了使用%lld输出的可能。2013年微软修复了这个问题,添加了对 %lld 的支持。

所以比较简单的区分方法就是看操作系统,如果是windows系统,那么一律使用__int64准没错。如果是linux或者是Mac系统,那么统一使用long long

我在网上找到了大神做的总结表,也可以直接参考下表:

变量定义

输出方式

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()

正确

正确

正确

正确

无法编译

参考资料:博客:C/C++的64位整型

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2021-10-17,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 Coder梁 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • long long 和 __int64
  • 历史遗留问题
  • cin、cout和scanf、printf的选择问题
领券
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档