我和朋友正在讨论，我们想知道为什么这么多开源项目决定采用C而不是C ++。 Apache，GTK，Gnome等项目选择了C，但为什么不用C ++，因为它几乎一样？
我们正在寻找导致这些项目（不仅是我列出的项目，而且是所有C项目）的原因，而不是使用C而不是C ++。主题可以是性能，易编程，调试，测试，概念等。
答案 0 :(得分：32)
C非常便携，远远超过10年前的C ++。
此外，C在Unix传统中非常根深蒂固。阅读“The Art of Unix Programming”，关于Unix and OO in general和关于specific languages on unix（包括C和C ++）的更多内容。
答案 1 :(得分：26)
有许多反例：一切都基于Qt。
另外，在我的Debian测试系统上：
edd@ron:~$ apt-cache rdepends libstdc++6|wc -l
4101
这是4101包，具体取决于基本的C ++库。为了比较，我获得了大约14,982个libc6或大约3.6个。但是，如果在开源领域没有任何C ++项目，那就不是了。
编辑： Thinko就我而言：由于C ++软件包也依赖于libc6，这个比例确实是
（14982-4101）/4101 = 2.65
所以在C中实现的包大约是C ++中的两倍。
答案 2 :(得分：24)
总结这一部分，Raymond声称“OO语言显示出一些倾向于让程序员陷入过度分层的陷阱”，而Unix程序员（以及扩展的开源程序员）则抵制了“厚胶”的陷阱。
本书中的Later，您会发现一些特别关于C ++的注意事项，例如“可能是C ++对OO的实现特别容易出错”。无论你是否同意，整篇文章都值得一读（我在这里很难做到这一点！ - ），并且参考书目指向许多其他相关研究和出版物。
答案 3 :(得分：19)
Linus Torvalds在C ++主题上多次肆虐 - 他使用C代替git，当然Linux内核主要是C：
你可以很容易地找到更多这些，虽然在他的本性中对这些事情有点讽刺，但有一些有效的观点。
其中一个更有意思的（无论如何，我坐的地方）是观察到C ++编译器和库（并且在某种程度上）比相应的C编译器更多的错误。鉴于两种语言相对复杂，这是有道理的。
它闻起来有点像“这里没有发明”（NIH）综合症，但是当你拥有整个Linux内核开发者基础时，你有时可以重新发明“正确的方法”。
答案 4 :(得分：17)
许多项目在C ++标准化之前就开始了，所以C是明显的选择，以后的改变会很难。 C在C ++之前大约十年被标准化，并且在更长时间内更加便携。因此，它在很大程度上是一个务实的决定，部分受到Unix大多数代码使用C语言的启发。
答案 5 :(得分：14)
C ++是一团糟。这是一个过于复杂的语言，如此复杂，只有少数人可以说他们知道所有的比特。并且更少的编译器真正符合C ++标准。
所以我认为原因是简单性和便携性。
如果你想要更高级和面向对象的编程，那么我认为C ++只是与Python之类的其他人竞争。 （请注意，我用C ++编程了几年，速度很快，并且有一些来自高级语言的功能，可以加速开发，而不是冒犯。）
答案 6 :(得分：13)
我在我的时间里参与了一些C ++项目，所有项目都以某种方式流下了眼泪。在最基本的层面上，事实是人们不可信任。他们不能信任编写好的代码，他们无法信任调试它，当他们不得不回来并在几周/几个月后再次修改它时，他们肯定不能信任它。
C代码在C ++中没有很多奇怪的东西，这使得它很难调试（构造函数/析构函数，cpp_initialize（）时间内静态全局对象发生的任何事情等）。这使得在开发和维护大型项目时更容易处理。
也许我是个luddite，但每当有人在我身边说“C ++”时，我都会感到沮丧。
答案 7 :(得分：13)
有些人已经提到了可移植性，但是在这一天，C ++的可移植性并不是一个大问题（它运行在任何GCC上运行，基本上都是什么）。但是，可移植性不仅仅是架构到架构或操作系统到操作系统。对于C ++，它包括编译器到编译器。
让我们讨论ABI或应用程序二进制接口。这基本上意味着“代码如何转换为汇编”。在C中，当你写：
int dostuff(const char *src, char *dest);
您知道您在目标文件中创建了一个名为_dostuff的符号（C全局名称在结果程序集中都以下划线为前缀）。但是在C ++中，当你写这个：
int dostuff(const char *src, char *dest);
int dostuff(const char *src, char *dest, size_t len);
甚至：
int dostuff(std::string src, std::string dest);
所有投注立即关闭。您现在有两个不同的函数，编译器必须创建每个函数，并且必须为每个函数指定一个唯一的名称。所以C ++允许（我相信C不会） name mangling ，这意味着可能这两个函数被转换为_dostuff_cp_cp和_dostuff_cp_cp_s（因此，使用不同数量的参数的函数的每个版本都有不同的名称。）
这个问题是（并且我认为这是一个巨大的错误，即使它不是C ++中交叉编译器可移植性的唯一问题）C ++标准留下了如何的详细信息这些名称直到编译器。因此，虽然一个C ++编译器可能会这样做，但另一个C ++编译器可以执行_cp_cp_s_dostuff，而另一个可能执行_dostuff_my_compiler_is_teh_coolest_char_ptr_char_ptr_size_t。这个问题加剧了（总是找到一种方法将这个词隐藏到你说或写的任何东西），因为你不得不破坏名称而不仅仅是重载函数 - 如何处理方法和名称空间以及方法重载和运算符重载以及... （列表继续）。只有一种标准方法可以确保您的函数名称实际上是您在C ++中的预期名称：
extern "C" int dostuff(const char *src, char *dest);
许多应用程序需要（或至少发现它非常有用）由C.Apache提供的标准ABI，例如，它几乎不能像跨平台和那样易于扩展如果它是在C ++中 - 您必须考虑特定编译器的名称损坏（以及特定的编译器版本 - GCC在其历史记录中已经更改了几次）或要求每个人普遍使用相同的编译器 - 这意味着每次使用向后不兼容的名称修改方案升级C ++编译器时，都必须重新编译所有你的C ++程序。
这篇文章变成了一个怪物，但我认为这说明了一个好点，我太累了，不能试图削减它。
答案 8 :(得分：9)
作为一个不喜欢C ++并且会在任何时候选择C的人，我至少可以给你关于这个主题的印象。 C ++有几个属性使它没有吸引力：
也就是说，C ++确实具有支持对象的好处。但归根结底，即使是大型项目，也可以在没有对象的情况下实现模块化。当你添加一个事实，即基本上每个可能为任何项目贡献代码的程序员都可以编写C语言时，如果你需要编写接近金属的代码，那么选择其他任何东西都很难。
所有这一切，许多项目都跳过C ++并转向Python，Java或Ruby等语言，因为它们提供了更多的抽象和更快的开发。当你添加他们支持从C代码编译/加载需要性能提升的部分的能力时，C ++会失去它可能具有的优势。
答案 9 :(得分：8)
如果你看一下最近的开源项目，你会发现其中很多都使用C ++。例如，KDE的所有子项目都是用C ++编写的。但对于十年前开始的项目来说，这是一个冒险的决定。当时C正式和实际上都是标准化的（编译器实现）。此外，C ++依赖于更大的运行时，并且当时缺少良好的库。您知道个人偏好在此类决策中起着重要作用，那时UNIX / Linux项目中的C员工远远大于C ++，因此新项目的初始开发人员更容易使用C语言。更大。此外，任何需要公开API的项目都会在C中执行此操作（以避免ABI问题），因此这将是支持C的另一个参数。 最后，在智能指针变得流行之前，用C ++编程会更危险。你需要更多熟练的程序员，他们需要过分谨慎。虽然C具有相同的问题，但使用边界检查工具/库更容易调试其更简单的数据结构。
还要考虑C ++只适用于高级代码（桌面应用程序等）。内核，驱动程序等不适合C ++开发。 C ++有太多“幕后”行为（构造函数/析构函数链，虚拟方法表等），在这样的项目中，您需要确保生成的机器/汇编代码不会有任何意外，并且不依赖于运行时图书馆支持工作。
答案 10 :(得分：6)
除了其他无疑可以提及的一个重要方面是C更容易与其他语言交互，因此在图书馆旨在广泛使用的情况下，即使是现在为此目的也可以选择C. / p>
为了举例说明，工具包GTK +（在C中）具有强大的OCaml绑定，而Qt和Cocoa（分别在C ++和Objective C中）只有这种绑定的概念验证。我认为将C语言与OCaml之外的语言接口的难度是其中一部分原因。
答案 11 :(得分：5)
一个原因可能是GNU coding standards特别要求你使用C.我能想到的另一个原因是自由软件工具在C语言中比C ++更好用。例如，GNU缩进不像C一样执行C ++，或者etags不解析C ++，也解析C。
答案 12 :(得分：1)
我可以列出更多原因
答案 13 :(得分：1)
首先，一些最大的开源项目是用C ++编写的：Open Office，Firefox，Chrome，MySQL，......
话虽如此，也有许多用C语言写的大项目。原因各不相同：它们可能是在C ++尚未标准化时开始的，或者作者对C更熟悉，或者他们希望更容易学习C曲线会吸引更多的贡献者。
答案 14 :(得分：1)
如果正确实现C非常快且非常便携且编译器在那里
对于每个可用的编译器，C ++都是不同的，库不同意，标准不匹配。
答案 15 :(得分：0)
你可以阅读Dov Bulka找到cpp中不能做的事情，你可以在Google代码上阅读tesseract ocr，你可以阅读很多东西 - 大部分都取决于你在哪里确定哪种语言代码优越。你在哪里读到c在开源中有比cpp更多的源代码？当然，你在c论坛上看到了这一点。那是在哪里。转到其他一些编程语言。进行相同的搜索，您会发现该代码具有更多开源。