【蓝因子教育】C 和 C++ 打起来了！最亲密的伙伴到现今的不爽？

70年代初，贝尔实验室创建了C语言，它是开发UNIX的副产品。很快C就成为了最受欢迎的编程语言之一。但是对于Bjarne Stroustrup来说，C的表达能力还不够。于是，他在1983年的博士论文中扩展了C语言。

于是，支持类的C语言诞生了。

当时，Bjarne Stroustrup明白编程语言有许多组成部分，除了语言本身，还有编译器、链接器和各种库。提供熟悉的工具有助于语言被广泛接受。在这种历史背景下，在C语言的基础上开发C++也是有道理的。

40年后，C和C++都在行业中得到了广泛使用。但是，互联网上的C开发人员认为C++是有史以来最糟糕的人类发明，而许多C++开发人员则希望有朝一日C语言灰飞烟灭。

1、究竟发生了什么事？

从表面上看，C和C++都可以满足相同的用例：高性能、确定性、原生但可移植的代码，可用于最广泛的硬件和应用程序。

但是，更让C自豪的是它是一门底层语言，更接近汇编。

而C++，从诞生第一天开始就充斥了各种奇怪的东西。例如析构函数这个黑魔法。自作主张的编译器。尽管很早C++就有了类型推断功能，但是80年代中期的开发人员还无法接受这个概念，因此Bjarne Stroustrup不得不删除了auto，直到C++ 11又重新添加回来。

从那以后，C++就不断加入各种工具来实现抽象。很难说C++是一种低级语言还是高级语言。从设计目的上来说，C++两者都是。但是在不牺牲性能的情况下，建立高级抽象是很困难的。于是C++引入了各种工具来实现constexpr、move语义、模板和不断增长的标准库。

从根本上讲，我认为C信任开发人员，而C++信任编译器。这是一个巨大的差异，单凭“两者的原生类型相同”、“while循环的语法相同”等简单一致是无法掩盖的。

C++开发人员将有这些问题归咎于C，而C开发人员则认为C++过于疯狂。我觉得站在C的角度看C++，这种说法也很正确。作为C的超集，C++确实很疯狂。一个经验丰富的C开发人员面对C++可能没有熟悉的感觉。C++不是C，这就足以引发互联网上的激烈争论。

那么，我们是否应该停止说C/C++，为这两个不幸的命名而感到悲哀吗？也不至于。

尽管C++的设计理念与C不一样，但是C++仍然是C的超集。也就是说，你可以在C++转换单元中包含C的头文件，这样依然可以通过编译。而这正是造成混乱的地方。

C++不是C的扩展，它是由不同的委员会、不同的人独立设计的标准。从逻辑上讲，喜欢C++理念的人会参与C++社区以及C++标准化的过程，而其他人可能会尝试参与C。无论是C的委员会还是C++委员会，他们表达意图和方向的方式只能通过各自的最终产品：标准；而标准是众多投票的成果。

然而，编译器很难知道它正在处理的是C头文件还是C++头文件。

extern “C” 标记并没有得到广泛一致的使用，而且它只能影响修饰，而不会影响语法或语义。头文件仅对预处理器有影响，对于C++编译器而言，所有内容都是C++转换单元，因此也就是C++。然而，人们依然会在C++中包含C头文件，并期望它“正常工作”，而大多数时候也确实可以正常工作。

那么，我们不禁想问：

2、由不同地方的、不同的人开发的C++代码如何保持C的兼容性？

恐怕很难。

最近，一位同事让我想起了康威定律：

"设计系统的架构受制于产生这些设计的组织的沟通结构。"

根据这个逻辑，如果两个委员不互相合作，则他们创造的语言也不会互通。

C++维护了一个与C及其标准库的不兼容列表。然而该列表似乎并未反映出许多C11和C18中添加、但在C++中不合法的功能。

然而，仅仅列出两种语言之间的不兼容性，并不足以衡量二者的不兼容性。

那些存在于C++标准库中但主要声明来自C的函数，很难声明成constexpr，更难声明成noexcept。C的兼容性会导致性能成本，而C函数是优化的障碍。

许多C的结构在C++中都是有效的，但无法通过代码审查（如NULL、longjmp、malloc、构造/析构函数、free、C风格的类型强制转换等）。

在C看来，这些惯用写法可能问题不大，但在C++中可不行。C++具有更强大的类型系统，不幸的是，C的惯用写法在这个类型系统中凿了一个洞，因此实现C的兼容性需要在安全性方面付出代价。

别误会，C++仍然关心C的兼容性，某种程度上。然而，有趣的是C也很关心C++，某种程度上。实话实说，C对C++的关心程度可能高于C++对C的关心。看来，每个委员会还是在乎另一个委员会的工作。但我们很不情愿。

C++知道，许多基础库都是用C编写的，不仅包括libc，而且还有zip、png、curl、openssl（！）以及许多其他库，无数的C++项目都在使用这些库。C++不能破坏这些兼容性。

但是最近，尤其是在过去的十年中，C++的规模已远远超过C。C++拥有更多的用户，并且社区更加活跃。也许这就是为什么如今C++委员会的规模是C委员会的10倍以上。

C++是不可忽视的力量，因此C委员会必须考虑不破坏C++兼容性。如果非要说一个标准追随另一个标准对话，那么如今C++是领头者，而C是追随者。

现在，C++处于稳定的三年周期中，无论是风雨还是烈日，抑或是致命的新疫情。而C每十年左右才发布一次主版本。不过这也很合理，因为作为一种较低级的语言，C不需要发展得那么快。

C语言的环境也与C++完全不同。C多用于平台，更多地用于编译器。每个人（甚至他们的狗狗）都会编写C编译器，因为该语言的特性集很小，所以任何人都可以编写C编译器。而C++委员会真正考虑的实现只有四种，而且在每次会议上这四种实现都会出现。所以，C语言中的许多功能都是与实现有关的，或者是可选支持的，这样各种编译器不需要做太多努力就可以声称自己遵从了标准，据说这样委员会的人会比较高兴。

如今，C++更加侧重于可移植性，而不是实现的自由。这又是一个理念的不同。

3、C的兼容性不重要

如果你是C开发人员，那么肯定会把C视为一种简洁的编程语言。但对于我们其他人而言，C的印象完全不同。

C是通用的、跨语言的胶水，可以将一切紧密地结合在一起。

对于C++用户而言，C就是他们的API。从这一点来看，C的价值在于其简单性。请记住，C++关心的那一部分C是出现在接口（头文件）中的C。我们关心的是声明，而不是定义。C++需要调用C库中的函数（Python、Fortran、Rust、D、Java等语言也一样，在所有情况下都可以在接口边界使用C）。

因此，C是一种接口定义语言。向C添加的内容越多，定义接口就越困难。这些接口随着时间的推移保持稳定的可能性较小。

那么，C++中缺少

是否重要？可能并不重要，因为这不太可能出现在公共接口中。

4、如今大家都在谈论C

过去，C的兼容性是C++的一大卖点。但如今，每个人（甚至他们的金鱼）都懂C。Rust可以调用C函数，Python、Java、一切语言都可以！甚至怪异的Javascript都可以在WebAssemby中调用C函数。

但是在这些语言中，接口是显式的。该语言提供的工具可以公开特定的C声明。当然，这比较麻烦。但这可以让接口非常非常清晰。而且还是有界的。例如，在rust中，调用C函数并不会迫使Rust牺牲某些设计来容纳C子集。实际上C是被包含进去的。

mod confinment {

use std::os::raw::{c_char};

extern"C" {

pub fn puts(txt: *const c_char);

pub fn main() {

unsafe{

confinment::puts(

std::ffi::CString::new("Hello, world!").expect("failed!").as_ptr()

5、编译器资源管理器

除非C的ABI发生变化，否则这段代码可以一直正常运行。而且Rust/C的边界非常清晰、不言自明。

因此，C++可能是为C兼容性付出最多的语言。

更糟糕的是，打开任何C的头文件，你很快就会发现一堆#ifdef __cplusplus。没错，C++的兼容性往往需要大量C开发人员的工作。兼容性一直是海市蜃楼。

6、我们该何去何从？

我认为两个委员会都在尝试更多地沟通。他们计划明年在波特兰召开会议（尽管这个计划可能会变）。沟通是一件好事。

但是鸡同鸭讲的沟通效果会非常有限。

也许可以将C++能接受的C子集约束在C99上？也许两种语言都需要找到一个共同的子集并独立地发展？也许extern C需要影响解析。如果C++经历了多个时代，那么C可能是其中之一。

也许我们需要接受将C作为C++的子集，但唯一的方法是将WG14融入到WG21中。

现状可能不会改变。C++可能永远也无法从自己的起源中解脱，而C可能永远都要与那些顶着C语言之名的肮脏特性战斗。