嘿，自从我在这里发布以来已经有一段时间了！我一直在忙于生活，尤其是在Hyperbeam，DigitalOcean和其他一些公司等一些公司工作。话虽这么说，但让我们进入当今话题的真正肉。 为什么C/C ++的发展如此混乱？

构建系统

我认为，C/C ++开发的最大痛点之一是构建系统，有很多许多构建系统，其中许多与其他系统不兼容。我们有CMAKE，PREMAKE，XMAKE，MSBUILD，BAZEL等。这实际上导致了有关标准的流行XKCD漫画，它们只是添加到混乱中。

这不是处理事物的方法，创建另一个构建系统或项目配置系统只会导致另一种尝试改善情况，而要使情况变得更糟。实际需要发生的事情是要有一个统一的构建系统。让我们看一下其他语言：Rust有货物，Zig拥有自己的内置构建系统，Haskell具有堆栈，地狱，甚至比C/C ++年龄较大的Fortran，它被称为FPM！我的观点是创建更多的事情是少。

标准化

另一个问题是C，但尤其是C ++具有特征蠕变。现在，这在C/C ++生态系统中是很正常的。但这导致编译器not being able to fully implement standards。到编译器赶上当前标准时，新标准已经淘汰。这就是为什么大量的人倾向于坚持一个标准而不遵守新标准的原因，因为这是一致的。

标准的要点不应是扩展语言或工具，而是按照词所暗示的，设置标准，其中编译器和相关的编译器和相关工具可以坚持并遵循书面的真实点。当每次遵循真理点时，这都是不可能的，这可能会完全消除任何以前的真理。

编译器兼容性

这可能是一个热门的看法，但我个人讨厌编译器特定的扩展名，例如GCC的C Extensions。之所以这样做的原因使您的代码库仅与该特定编译器兼容，而没有其他编译器。这意味着对于使用Clang，TCC，MSVC或其他C工具链的任何人，除非他们安装GCC，否则它们会很不幸。当我已经在系统上安装了该语言的编译器时，我不需要为我要编译的语言安装X特定的编译器。但是，如果扩展程序是在编译器和工具链之间共享的，那将是很棒的！

软件包管理

我在第一部分有关构建系统的研究中谈到了这一点，但是我们将更多地挖掘出来，因为这对我个人而言一直是一个痛苦的地方。老实说，C中的包裹管理很糟糕。没有搜索（不获取）软件包的中心位置，由于构建系统混乱，您使用X构建系统遇到了包装，因此您必须将其构建脚本移植到您的构建系统，软件包管理在整个平台之间不一致（尽管Microsoft的vcpkg试图解决此问题），并且由于不一致，太多的选择以及其他影响它的问题，您还需要处理更多问题。

>

最后一句话

您怎么看？您是否认为C/C ++开发可以改善，如果是的话，您对的看法如何？提醒保持冷静，不要攻击人们发表轻松的意见。我认为这是一个多年来从事C/C ++开发的人，显然没有反映他人的观点。