水木社区手机版
- 主题:gcc这什么情况
- 这种改变会break很多老代码，值不值得用一个std=XXX 去搞定
【 在 hgoldfish 的大作中提到: 】
: 那么可以弄个 int 类型，指向本机器效率最高的类型，同时最低不于低于 32 位。
: 不过我觉得随着时代的发展，其实也没啥必要，直接指定 int = int64 就完事了。
:
--
FROM 221.218.160.* - 不是我用，是其它部门给的库接口是Longlong
接口瞎jb写
我代码都统一用stdint的，结果这里居然不行
本身gcc也只是报个warning，但我们上了clangtidy，直接这个不给过了
【 在 z16166 的大作中提到: 】
: 历史包袱总归是有的。这跟牙膏厂的处理器还支持real mode、Windows还支持WoW32一个道理
: 你为啥用long long呢？
:
--
FROM 111.183.63.* - 有啥奇怪的
类型不一样
c++是强类型
【 在 lwp 的大作中提到: 】
: candidate function not vi able: no known conversion from 'uint64_t *' (aka 'unsigned long *') to 'unsigned long long *' for 1st argument
: 难道不都是64位，在这抱怨啥？
: clang-tidy居然也报warning
: ...................
--
FROM 114.249.28.* - 我的意思是弄个新语言的时候可以这么干。
c/cpp 还是兼容为主。
【 在 z16166 的大作中提到: 】
: 这种改变会break很多老代码，值不值得用一个std=XXX 去搞定
--
FROM 120.41.213.* - c++20已经是了啊
【 在 lwp 的大作中提到: 】
: 我就一直呼吁把unit8，16，32，64这种直接定义为关键字
: 正常人没几个会愿意用short long这玩意的吧
: :
--
FROM 114.249.28.* - 如果我是你的话，我会在这里做个强转。同时判断两边的值是否溢出。溢出的话就打印个警告。
【 在 lwp 的大作中提到: 】
: 不是我用，是其它部门给的库接口是Longlong
: 接口瞎jb写
: 我代码都统一用stdint的，结果这里居然不行
: ...................
--
FROM 120.41.213.* - 如果是问题，可以找对应的人沟通的吧，无法沟通的，抛出去让有权裁决的人拿主意
如果没有问题，那没啥好说的
【 在 lwp 的大作中提到: 】
: 不是我用，是其它部门给的库接口是Longlong
: 接口瞎jb写
:
: ...................
--
FROM 221.218.160.*