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

刻意设计出来的，为了匹配当时的处理器的一个 world ，参考： https://www.quora.com/Why-are-type-sizes-inconsistent-among-different-platforms-eg-short-int-long-in-C

如果让我从 c99 前的整数类型和 java 的整数类型二选一，我还是选宁愿用 c 的

当然是失败设计。

rust 的更好点。i8,i16,i32,i64 非常清楚。c 的 int 都在不同平台叫同一个名字。然而内存占用不一样。非常坑。

编程语言是服务于程序，而不是服务于程序员的，C/C++的很多设计都是出于性能考虑，数据类型也是一样的，C/C++都是 70 年代产生的语言，当时内存可能都不到 1M ，现在内存虽然大了，但是 CPU 缓存可能也就十几 M ，更别说还有嵌入式设备，而有些需求对于性能的追求是没上限的，很多 C 库，底层实际上是 SIMD 和汇编。

时代的局限性，盖茨都说过 64k 已经够用了。

这样做是为了实现通过宏检测 feature 后，可以一份源码在不同平台使用不同编译器也能编译出正确的程序

很大部分是历史原因，各种类型设备的出现，都需要 C/C++ 编写能运行在之上的程序（比如驱动），C++11 标准化的 (Fixed width integer types)[https://en.cppreference.com/w/cpp/types/integer] 就是为了方便编写可移植性代码，以前的都是完全由开发者用宏来处理数据类型的差异。

目前正在开发跨平台应用，不等宽确实是一个不方便的设计。但是这些在设计过程中都可以规避，现在的 C++标准支持 int32_t 类似的 Fixed width integer types 定义。如果在实践过程中实在需要根据平台来使用不同长度的类型，一般是先定义一个类型，然后再使用不同平台的宏来定义不同长度。

早期硬件什么设计都有，int long 这些类型不定长反而才能可移植。你知道 char 有可能不是 8bit 吗？
至于现在跨平台基本都在用 stdint.h 里面那些定义，C99 就支持了。

@vituralfuture 完全可以通过 feature 检测后用 typedef 来换数据类型。int 不等宽除了方便 compiler 实现，真没啥实际好处。

说白了 int long 不定宽是就刻意设计的，目的就是为了适应多样化的硬件，方便移植，保持最佳性能。
posix 和 libc 也是从那个时代过来的，一直需要维持 API 兼容，所以这才是历史问题。

要甩锅那得甩给早期计算机的制造公司，尤其是 DEC

UNIX 是在 PDP-7 开发出来的，而 PDP-7 的一个 Word （当时的最小操作单位）是 18 字节：
https://gunkies.org/wiki/PDP-7

在 C 语言诞生的那个年代，既有 PDP-11 （ C 语言初版诞生的平台），使用现在大家熟知的 16bit / 32bit / 64bit 操作方式；也有 PDP-12 ，使用的是 12-bit ，以现在的标准来看够奇怪吧。

如果当时直接定死了各个基础类型的宽度，那么想要做源码级移植就麻烦多了。

就像如此简单的代码：

int number = 12;
printf("Number: %d\n", number);

int 是 18-bit 还是 12-bit ，又或者是 16-bit ，都由目标机器的编译器自己决定，在当时来看显然是很省事的。

发明人哪能预料到后来会统一为 8 / 16 /32 / 64 bit 标准呢

---------------

当然啦，ANSI / ISO 也有部份责任，第一个 ANSI C 标准制定的年代，已经是 8 / 16 /32 / 64 bit 标准的时期了，完全可以区分得更清晰一些，比如这样：

int 必须比 short 宽，long 必须比 int 宽

可惜标准只规定了最低限度，搞得后来不同系统的 int 和 long 都一塌糊涂。到了 C99 就只能用 macro 打补丁。

@cnbatch 勘误一下，DP-7 的一个 Word （当时的最小操作单位）是 18 比特（不是字节）

补充一个：IBM 的“锅”也不小，DEC 之所以这么设计，可能是受到 IBM 的影响（毕竟要跟 IBM 竞争）。PDP-1 诞生前的 IBM 机器，字长就是 36-bit ，这里有发展史可以看：
https://en.wikipedia.org/wiki/Word_(computer_architecture)

1970 年之前的硬件操作数长度标准简直乱作一团

@moudy 早期 C 语言可没有 typedef 这种做法，有人提到这么一句
there is no "typedef" in early C
出处： https://news.ycombinator.com/item?id=13441621

这个问题的本质是 C/C++定位是系统编程语言，数字类型的是为了方便在不同指令集之间移植来设计的，比如说：

* 所有类型都只有最小宽度而没有绝对宽度，因为不是所有指令集都有操作各种宽度的指令
* int 就是在那个平台寻址范围内做下标比较合适的长度
* short 就是可能比 int 节省空间，但是至少有 16 位； long 就是至少有 32 位

当然我也觉得理想是美好的，现实是骨感的，这些语言出现不久互联网就爆发了，有了跨机型交换数据的需求，导致这些依平台而变的类型不好用。

理论上说交换格式可以和内存里的数据类型分离，比如内存里的 struct 用 int, long 等类型，交换时翻译到到固定长度的 char[]（这样还解决了 endianness ），但显然没有几个人这么勤快。

当然我觉得 long long 出现时，这个情况已经很明显了，应该直接定义 int64 而不是新增一个关键字。

还是因为历史的局限性吧? 当时的计算机处理器规格都各做各的, 兼容机都算是个不小的突破, 但是各家的位宽都不一样, 很多兼容软件的传递方式是以源码形式传递的, 就是为了方便用户编译到自己的机器上,

@cnbatch 我发出来才看见你的，我觉得你说的“int 必须比 short 宽，long 必须比 int 宽”虽然让部分初学者可以更清楚的了解这些类型的区别，但是与系统编程语言的定位不符合。比如说我记得早期的 64 位机就有完全不支持 16 位长度的指令集，这样 short 也必须是至少 32 位，那么 int 就得 64 位，long 不能 128 位吧？

@paopjian 这个问题到现在还有啊，比如嵌入式系统 32 位的已经很高级了，用 8 位机的也大有人在，很多机器连整数除法都做不了，这也是 C/C++最大的客户群。

这不是设计问题，是当时的硬件问题

@billccn 或许，特殊机器可以特殊对待，比如以编译器 extension 的形式去处理。
假设“标准状况”下，char: 8-bit, short: 16-bit, int: 32-bit, long: 64-bit
那么开启 extension 就无视标准规定，按照机器的硬件手册内容去做。

如果硬件级别无法支持“假设的标准状况”，那就强制必须使用 extension 模式。

当然啦，这都是马后炮了，我有这种想法（强制开启 extension ）主要是因为知道 Linux 内核源码长期以来大量使用编译器扩展模式。微软编译自家系统时应该也是这样（ MSVC 也有自己的 extension ）。对于 20 世纪 80 年代的标准制定者而言，可能都预料不到编译器 extension 会用得满天飞。

当初差不多没有标准化的 8/16/32 ， 当时的字长一大堆，有 9 12 啥的，你这论调属于事后诸葛亮，新语言基本上都是 64 位处理器起跳了

当时电脑, 能扣几个字节都干的

rust 的 usize 也是不定宽的啊，你为什么说“例如 i64 、u32 、int64 、usize ”

好比工地钻头，尺寸不一 你说他们不严谨？不照样摩天大楼如雨后春笋冒出来嘛？

都是符合当时的业务背景需求罢了， 不是那么严谨的产业 只是基础服务设施 不行在升级迭代就行了. 至于内存？不够就加， 硬盘不够就扩容; 实在到了拿节骨眼上， 企业也会舍得花钱重建;
至于一开始就一眼观望未来产生精妙的设计结构 的计算机语言 符合未来几十年的体系 业务。 只有两种可能：
1. 运气好 营销也到位 存粹撞上了 该的。
2. 造物主说的，就要这么干 我说的就是对的。
普通人？忙着吃饭挣钱过好日子呢。造福全球人类的计划怕是一提出来 结合设计经费； 在资本家看来这是他们的命

@cnbatch #14 早期是早期，后面 C90 C99 还不在这个问题上做出更新就是不负责任。也直接导致了 64 位 c 编程时 int long longlong 实际宽度的混乱。

@billccn #17 指令集和数据宽度没直接关系哦。64 位指令也可以只操作 byte halfword

@ugpu #24 技术标准上定一个指标，不给指标上下界真的是不严谨。老罗在星巴克被中杯 大杯 超大杯都折磨成啥样了。

@moudy 定了呀, 常规的就按：int 4 个字节 bool 一个字节 char 一个字节 还有 short. 够用了; 很满足当时的需求了.

@moudy 这种帖子 老技术都应该知道没啥意义；不管 op 的出发角度是恶意的还是友善的;
无非证明一个: 在事情已经发生了 跳出来说 xxx 当初的设计怎么怎么不对;
这好比什么。举几个恶臭的例子 ？
《一座城市 一座老桥, 要拆了重建，跳出来个新人. 你们当初干什么去了！ 怎么不 xxxx ！ 一副说教嘴脸, 》
《项目上线了 没达到预期。老二站出来反讽当初拍板的人， 我当时就说了 xxxxx 》

技术角度看没问题; 就是当初没考虑到扩容. 但是没有人能考虑未来的事情.
为什么不正向看？
1. 迭代说明升级了 行业欣欣向荣 起码这玩意有价值 需求在增加导致原有支持不满足目前场景; 需要改进
2. 提供了新的就业机会
3. 产生了其他技术的融合

肯定是失败的，按照兼容性和可移植性来说，肯定应该使用绝对值。比如二进制文件就得用 int64 ，后来的 java 能够跨平台也是不同平台的大小是一致的。就算架构使用的位数不同，使用绝对值也可以更好地模拟，就算是 10 位机，也可以用 int10 来模拟 int8 ，int20 来模拟 int16 ，但是 C/C++这样就更可能出问题。

如果按每个平台的特性来说，定义几种特殊类型就够了，比如 ifast 和 usize ，现在这样连 char ，short 和 long 标准定义上都没有固定的长度就太扯淡了。使用特殊类型也能更方便地检索出这里是平台相关的代码，而不是像 C/C++这样默认全都是平台相关的，只有写 intXX_t 才是平台无关的。

@ugpu #28 也只是大家这么觉得而已，LLP64, LP64 现在依然在打架。 具体到项目踩坑：enum 在不同编译器上默认大小不一样，导致存储的数据换了编译器读不出来，也是够了。

@moudy
如果你说 LLP64 和 LP64 那这是操作系统所谓的官方编译器的事情, 是人为原因导致的., 语言本身是没问题的 语言规范了 byte short int bool ; 我的意思是 语言设计之初考虑的是字节流 在当时时代主流设计上的规范, 并不需要为后期的拓展负责; 以及正式有了这些问题才能推进后期高级语言的规范...

glibc 代码里面那一层一层的 define 看着就难受, musl 稍好一些但也好不到哪儿去, 还有就是文档也是一拖而且注释极少