现在来看, C/C++ 的 int、long 等不定宽类型是失败的设计吗?

291 天前
 w568w
如题,今天给 C 库写其他语言 binding 的时候想到的。

论据 1:C/C++ 之后,几乎所有语言都 (1) 定死了各个整数类型的宽度(如 Java ),或者 (2) 换用定宽类型(例如 i64 、u32 、int64 、usize )。即使 C 自己也引入了 int64_t 这样的固定宽度类型。

论据 2:非常不利于编写可移植的库。比如用两个不同编译器编译出的代码,虽然函数声明一样,但因为一边 long 是 64 位整数,另一边是 32 位整数,导致不能互相调用。

论据 3:不确定宽度导致程序员不得不随时检查数值范围,一旦疏忽(例如,换了新平台或者编译器)很容易造成溢出问题。为了检查,编写大量含宏代码,给程序员带来额外心智负担。

论据 4:使数值类型系统变得过于复杂,很多场景下并不需要严格区分 long long 、long 、int 、short 、char 。但程序员由于认识不清楚而随意使用,反而可能造成 linter 不能正确给出 warning 。

---

这个 int 、long 不定宽的规定是当时随意决定的吗?还是刻意设计出来的?为什么直到今天还有大量 C 库、接口仍在使用这样的类型?(例如 POSIX 、libc 、OpenMP )
4546 次点击
所在节点    程序员
33 条回复
mayli
291 天前
当初差不多没有标准化的 8/16/32 , 当时的字长一大堆,有 9 12 啥的,你这论调属于事后诸葛亮,新语言基本上都是 64 位处理器起跳了
iorilu
291 天前
当时电脑, 能扣几个字节都干的
tdxdxoz
291 天前
rust 的 usize 也是不定宽的啊,你为什么说“例如 i64 、u32 、int64 、usize ”
ugpu
291 天前
好比工地钻头,尺寸不一 你说他们不严谨?不照样摩天大楼如雨后春笋冒出来嘛?

都是符合当时的业务背景需求罢了, 不是那么严谨的产业 只是基础服务设施 不行在升级迭代就行了. 至于内存?不够就加, 硬盘不够就扩容; 实在到了拿节骨眼上, 企业也会舍得花钱重建;
至于一开始就一眼观望未来产生精妙的设计结构 的计算机语言 符合未来几十年的体系 业务。 只有两种可能:
1. 运气好 营销也到位 存粹撞上了 该的。
2. 造物主说的,就要这么干 我说的就是对的。
普通人?忙着吃饭挣钱过好日子呢。造福全球人类的计划怕是一提出来 结合设计经费; 在资本家看来这是他们的命
moudy
290 天前
@cnbatch #14 早期是早期,后面 C90 C99 还不在这个问题上做出更新就是不负责任。也直接导致了 64 位 c 编程时 int long longlong 实际宽度的混乱。
moudy
290 天前
@billccn #17 指令集和数据宽度没直接关系哦。64 位指令也可以只操作 byte halfword
moudy
290 天前
@ugpu #24 技术标准上定一个指标,不给指标上下界真的是不严谨。老罗在星巴克被中杯 大杯 超大杯都折磨成啥样了。
ugpu
290 天前
@moudy 定了呀, 常规的就按:int 4 个字节 bool 一个字节 char 一个字节 还有 short. 够用了; 很满足当时的需求了.
ugpu
290 天前
@moudy 这种帖子 老技术都应该知道没啥意义;不管 op 的出发角度是恶意的还是友善的;
无非证明一个: 在事情已经发生了 跳出来说 xxx 当初的设计怎么怎么不对;
这好比什么。举几个恶臭的例子 ?
《一座城市 一座老桥, 要拆了重建,跳出来个新人. 你们当初干什么去了! 怎么不 xxxx ! 一副说教嘴脸, 》
《项目上线了 没达到预期。老二站出来反讽当初拍板的人, 我当时就说了 xxxxx 》

技术角度看没问题; 就是当初没考虑到扩容. 但是没有人能考虑未来的事情.
为什么不正向看?
1. 迭代说明升级了 行业欣欣向荣 起码这玩意有价值 需求在增加导致原有支持不满足目前场景; 需要改进
2. 提供了新的就业机会
3. 产生了其他技术的融合
junkun
290 天前
肯定是失败的,按照兼容性和可移植性来说,肯定应该使用绝对值。比如二进制文件就得用 int64 ,后来的 java 能够跨平台也是不同平台的大小是一致的。就算架构使用的位数不同,使用绝对值也可以更好地模拟,就算是 10 位机,也可以用 int10 来模拟 int8 ,int20 来模拟 int16 ,但是 C/C++这样就更可能出问题。

如果按每个平台的特性来说,定义几种特殊类型就够了,比如 ifast 和 usize ,现在这样连 char ,short 和 long 标准定义上都没有固定的长度就太扯淡了。使用特殊类型也能更方便地检索出这里是平台相关的代码,而不是像 C/C++这样默认全都是平台相关的,只有写 intXX_t 才是平台无关的。
moudy
290 天前
@ugpu #28 也只是大家这么觉得而已,LLP64, LP64 现在依然在打架。 具体到项目踩坑:enum 在不同编译器上默认大小不一样,导致存储的数据换了编译器读不出来,也是够了。
ugpu
290 天前
@moudy
如果你说 LLP64 和 LP64 那这是操作系统所谓的官方编译器的事情, 是人为原因导致的., 语言本身是没问题的 语言规范了 byte short int bool ; 我的意思是 语言设计之初考虑的是字节流 在当时时代主流设计上的规范, 并不需要为后期的拓展负责; 以及正式有了这些问题才能推进后期高级语言的规范...
my3157
289 天前
glibc 代码里面那一层一层的 define 看着就难受, musl 稍好一些但也好不到哪儿去, 还有就是文档也是一拖而且注释极少

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://ex.noerr.eu.org/t/1116958

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX