根据一位C++开发人员的说法，C语言的问题

70年代初，贝尔实验室创建了C语言，作为UNIX开发的副产品，它很快成为最流行的编程语言之一，但对于Bjarne Stroustrup来说，它的表现力不够。因此，在1983年，作为他的博士论文的副产品，他扩展了C语言。

当时，Bjarne Stroustrup了解到编程语言有很多组件，不仅有语言、编译器，还有链接器和库。提供熟悉的工具也更容易采用。在这种历史背景下，C++基于C语言是有意义的。

C和C++在业界都被广泛使用，但是上网5分钟，C开发人员就会告诉你，C++是最可怕的人工创造，而许多C++开发人员则在等待C语言最终在地狱的烈焰中燃烧的那一天。

从表面上看，C和C++迎合了相同的用例：针对最广泛的硬件和应用程序的高性能、确定性、本机但可移植的代码。

从第一天起，C++就有了魔力。黑暗巫术：破坏者。突然，编译器开始自己做事情了。它在很早的时候也有类型推断，但是80年代中期的开发人员还没有完全准备好，Bjarne Stroustrup被迫删除了auto，直到它被重新添加到C++11中。

从那时起，C++获得了越来越多的工具来构建抽象，我认为说C++是一种低级语言还是高级语言是不公平的。但在不牺牲性能的情况下构建高级抽象是困难的。C++当时需要工具来实现这一点：stexpr、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++委员会实际上只会考虑4种实现，所有这些实现都会在每次会议上出现。因此，C中的许多功能都是由实现定义的，或者有选择地得到支持，这样现有的各种编译器就可以声明符合要求，而不需要做太多的工作，我听说这会让监管机构感到高兴。因此，C中的许多功能都是由实现定义的，或者有选择地支持，这样现有的各种编译器就可以声明符合要求，而不需要做太多的工作，据我所知，这会让监管机构感到高兴。

现在的C++更关注可移植性，而不是实现的自由度。还有另一个哲学上的不同之处。

从理论上讲，我的P2178论文的某些部分会影响C语言兼容性，在这种情况下，似乎没有一个选项令人满意。

你可能会被告知，你必须首先将你的功能放到C中，这意味着更多的会议。你可能无法参加会议，因为C有严格的出席规则-排除不愿支付数千美元成为ISO成员的个人。这是因为C委员会被迫严格遵守ISO规则。

如果标准刚刚发布，也可能需要十年的时间。最重要的是，如果C委员会不理解或不关心您试图解决的特定问题，它可能会一事无成。他们可能没有带宽来处理它。而且您可能没有带宽处理C。毕竟，您加入C++是为了改进C++。实际上，如果这个房间邀请您“与C委员会交谈”，您的建议很可能是失败的，即使在房间里没有人的情况下也是如此。如果您加入C++是为了改进C++。事实上，如果这个房间邀请您“与C委员会交谈”，您的建议很可能是失败的，即使在房间里没有人的情况下也是如此。

另一种可能的情况是，C委员会接受与C++中存在的版本略有不同的提案版本。是真的吗？让我们把它变成一个宏。查16_t？让我们将其设为tyecif。查32_t？不一定是UTF-32。STATIC_ASSERT？_STATIC_ASSERT。

名单还在继续。我们应该责怪C吗？大概不会吧。他们的委员会做他们认为对他们的语言最好的事情，反之亦然。在C++20中，指定的初始化器受到C的启发，但它们略有不同，因为否则它们将不符合C++初始化规则。

我是问题的一部分。C有VLA。我会投票反对在标准C++中采用它的提议，因为有太多的安全问题。在C++中添加_Generic的建议简直是胡说八道。我不确定_GENERIC是否试图缓解缺少模板或缺少重载的问题，但是C++拥有这两个特性--在我看来，_GENERIC并不符合我想象中的C++的总体情况。

这两个委员会在关心另一种语言的程度上似乎也不一致，有时我们会做得很长(std：：Complex)，有时我们一点也不关心(静态数组参数)。

这是无可奈何的。别忘了，每个委员会都是一群人，在不同的时间在不同的房间里投票，试图控制结果会违背拥有一间房间的目的，把人放在同一个房间里也是不现实的。ISO可能会反对，而不平衡的参与将使C人处于巨大的不利地位。

如果您是一名C开发人员，我想您会认为C是一种简洁的编程语言，但对于我们其他人来说，C则是另一回事。

对于C++用户来说，C就是它的API。考虑到这一点，C的价值在于它的简单性。记住，C++关心的C子集是出现在接口和头文件中的子集。我们关心的是声明。没有定义。C++想要调用C库中的函数(或者Python、Fortran、Rust、D、Java等，在所有情况下都可以在接口边界使用C)。

从这个角度来看，C是一种接口定义语言。向C添加的花哨越多，定义接口就越困难。而且随着时间的推移，这些界面保持稳定的可能性就越小。

那么，C++中缺少<；threads.h>；有关系吗？可能没有，因为这不太可能出现在公共接口中。

在过去，C兼容是C++的一大卖点，然而现在，每个人和他们的金鱼都了解C。Ruust可以调用C函数。蟒蛇。爪哇。一切！即使是疯狂的Javascript也可以调用WebAssemby中的C函数。

但是在这些语言中，接口是显式的，语言提供了工具来公开特定的C声明，当然，它更麻烦，但是它使接口非常非常清楚。例如，在Rust中，调用C函数并不会迫使Rust牺牲一些设计来容纳C子集。不，C是包含在内的。

修改限制{use std：：OS：：raw：：{c_char}；extern"；C"；{pub FN put(txt：*const c_char)；}}pub FN main(){unsafe{confinment：：put(std：：ffi：：cString：：new("；Hello，world！"；).Expect("；FAILED！"；).AS_PT.。}}。

此代码将一直工作到C ABI更改为止。并且铁锈/碳的边界是自我记录的，并且清晰可见。

更糟糕的是，打开任何C头文件，你很快就会发现一堆#ifdef__cplusplus。没错，C++兼容性通常需要C开发人员做很多工作，兼容性一直是海市蜃楼。我记得这条推文：

恼怒：充满#ifdefs is_not_"；可移植代码的代码块"；。它充其量也就是被移植了很多次的代码。这有很大的不同。

-Fabian Giesen(@rygous)2020年2月3日。

我认为两个委员会都在试图进行更多的讨论。甚至计划明年在波特兰举行一次联合会议(尽管计划可能会改变。大流行。波特兰…)。.沟通良好。

但是猫和狗只能做这么多的交流，这两种语言的设计支柱可能是不协调的，我会因为提出一个模板而被烧死。但是在大声抱怨C没有模块和命名空间系统，以及那个该死的宏是什么之前。

也许可以限制(！)。C++接受C99的C子集？也许两种语言都需要找到一个公共子集(不是这一个)并独立发展？也许外部C需要影响解析。如果C++有纪元，那么C可以是纪元。

也许我们需要将C作为C++的子集，但唯一的方法是将WG14分解为WG21。

有可能现状不会改变。C++可能永远不会从它的起源(核心被丢弃)中解脱出来，而C则注定永远不能呼吸，以免它们沉没一大堆胆敢以它的名字命名的邪恶的特性。