摘要：原文链接：https://baijiahao.baidu.com/s?id=1693215018575246509这是一个复杂的问题，结合在一起：事实，过时的事实，夸大的说法和根深蒂固的未经证实的信念。事实：-学习C比C ++容易得多：一个...
原文链接：
https://baijiahao.baidu.com/s?id=1693215018575246509
这是一个复杂的问题，结合在一起：事实，过时的事实，夸大的说法和根深蒂固的未经证实的信念。
事实：
-学习C比C ++容易得多：
一个好的Java或Python程序员在使用C指针时会遇到一些问题，比如缺少类，但是学会可能只需一两个月。这是一些雇主愿意投资的东西。相比之下，要想达到C ++的合理水平可能要花费一年的时间。不是专家水平，只是合理水平。与C相比，这是获得新人才的一大不利条件。
C ++与C的表面相似性引起很多问题：
最佳C ++实践与C和Java最佳实践完全不同。因此，熟练的C程序员往往会在工作量，可读性，错误和运行时速度方面低效率地编写C ++代码。（更正：错误创建效率更高）。一个好的C程序员可能会以C ++的方式使用C ++造成麻烦。经验丰富的C ++编码人员将轻松避免这些问题。
典型的错误包括：使用（原始）指针，手动管理资源，通过值而不是通过引用传递参数，（过度）使用不安全的C操作，使用宏，转到，既不使用range-for也不使用auto，未正确使用重载，以及还有很多。这些错误对于初学者来说是很自然的，并会在以后引起很多麻烦。
C ++中的幕后资源管理：
例如，琐碎的事可能会在堆上分配内存。这可能会在许多以堆分配为忌讳的嵌入式系统上引起麻烦。有很多解决方法，但是它们需要有关分配器的纪律和知识。std::string
C ++中的异常代价：
异常支持实际上在CPU方面是免费的，但就展开信息占用的RAM而言，其开销为非零。这使得C ++在嵌入式系统上更成问题。可以禁用异常，但这会使错误处理复杂化，尤其是在构造函数中。
大型标准C ++库：
即使输入最小的可执行文件，标准C ++库的目标代码通常也很大。这是实现的问题，某些编译器可能能够减小此大小。同样，可以避免占用所有这些内存的标准C ++部分（例如语言环境和iostream），但是那样的话，它就不会完全是C ++。
大C ++代码的编译比编译类似的C代码要慢：
希望C ++模块可以解决此问题（在C ++ 20或C ++ 23中）。但是目前，编译速度是许多聪明人已经从事了十多年的一个实际问题。我希望模块能够将其纳入C ++ 20，并且将得到修复。在此之前，有多种方法可以通过更智能的软件工程来最大程度地减少此问题，并且已经有很多关于该主题的CppCon演示。
过时的事实：
C比C ++具有更好的硬件支持。十年或两年前曾经如此。如今，即使是GCC（最便携的编译器）也是用C ++编写的。这意味着，如果GCC可以是系统上的本机编译器，则C ++可用。如果GCC可以交叉编译，则很有可能可以为系统编译C ++。总体而言，只要编译器团队愿意移植GCC（甚至是clang）而不是开发自己的编译器，C ++就可以像C一样可移植。
但是请注意，正如我在上面的事实部分中所写的那样，移植标准库可能是一个问题。这主要是由于其大小以及对堆的使用。移植库的另一个障碍是底层原语，这对于移植来说可能并不重要。这并不意味着核心语言的可移植性不如C。
夸大的说法：
引用Linus对C ++的仇恨的人们忘记了在1991或1992年的某个时候，Linux已成功使用G ++而不是GCC进行了编译。当时，G ++极具bug，并且生成的代码比GCC差得多。不仅如此，它还早于C ++标准。当时，G ++甚至没有适当的模板支持。Linux内核长期未使用G ++进行编译。
我想许多C程序员都被旧的C ++编译器困扰了，形成了他们的见解，并且厌恶。从那时起，可怕的C ++神话开始传播。实际上，C ++曾经是可怕的。有趣的是，有些学校仍在教授古老而又可怕的C ++（Borland C ++ ，Sergey Zubkov对“哪个是C语言的更好编译器，Dev C ++或Turbo C？”的回答）。
没有事实根据的信念。
C ++有许多问题和弊端，但是最大的反对不是植根于工程学或计算机科学，而在于心理学。
不要误会我的意思，在C ++和C中也有很多不好的的事情。但是，很多次决策不是基于这些事实，而是基于信念。
但是，即使是聪明人，也会不惜一切代价抹黑与他们的信念相抵触的证据。
