为什么C ++仍然“混合”

在一个相关的问题上，已经阐明了为什么C ++在许多方面与C不兼容。但是，C ++仍然是“混合” *语言。不幸的是，许多程序员仍然将C ++视为“具有流和内置字符串的C”。这导致了非常糟糕的书面代码，因为它既不是C ++也不是C。恕我直言，如果语言/编译器在某种程度上强迫程序员编写更优雅的代码，那会更好。那么是否有理由保持现代C ++（例如C ++ 0x和将来的版本）混合在一起？

_{*混合是指程序员决定是否使用他/她：标准字符串和流，类，默认名称空间以外的名称空间等。}

是的，有一个很强的理由：C ++代码几乎总是必须调用现有的C代码。我们能做的最好的事情就是使编写好的代码变得容易。语言设计师无法做任何事情来使编写不良代码成为不可能。

恕我直言，如果语言/编译器在某种程度上强迫程序员编写更精美的代码，那会更好。

不，不会。完全没有 为了简单地说明为什么，请定义优雅，然后我敢打赌，十个人将继续不同意您的看法。

语言强制的编码样式确实非常糟糕。更不用说所有将被破坏的旧代码。

值得注意的是，标准字符串和流类实际上 suck。std::string没有Unicode支持，您可能会想到的最肿的接口。这些流具有巨大的开销和糟糕的设计，甚至依靠虚拟继承，函数指针const char*和类似的丑陋方法。我不会因为用自定义类完全替换这两个类/类组而对任何人造成惩罚。

对于白板样式的代码，不使用类和名称空间是很好的选择，并且有许多库提供的功能不在类中。强制类是一个非常糟糕的主意。

C ++是混合的，不是因为它允许人们编写C风格的代码，而是因为它支持多种编程范例，例如过程，面向对象和通用。C ++不会强迫您采用一种做事方式，这就是它的强项，因为使用不同的范例可以更轻松地解决不同的问题。

恕我直言，如果语言/编译器在某种程度上强迫程序员编写更精美的代码，那会更好。

然后，您首先必须定义 优雅的含义。然后，您将必须查看您对Elegant的定义是否适合使用C ++的所有问题领域和平台。很适合编写Windows文字处理器的编码风格可能完全不适合编写嵌入式系统。

考虑编写C ++代码以在DSP上运行。首先，用于该DSP的C ++编译器可能根本不支持某些C ++功能，例如流。其次，您受到CPU速度以及可能的内存的严重限制，因此某些C ++功能可能会扼杀您的性能。例如，为了提高速度，您可能必须避免使用虚函数。与您在PC上使用的语言相比，这些考虑将彻底改变您的编程风格，而C ++允许这样做。

总而言之，C ++是一门庞大而复杂的语言，具有许多功能。这些功能的任何子集可能不适用于特定项目的原因有很多：速度，可移植性，编译器支持，甚至程序员的经验和熟悉度。出于这个原因，这种语言迫使开发人员在执行任何给定任务时使用某些功能而不是其他功能。想想Java，在Java中语言要求每个函数必须是类的方法。在许多情况下，创建仅用于包装方法的类很尴尬且不必要，但是您必须这样做，因为语言会迫使您这样做。

恕我直言，如果语言/编译器在某种程度上强迫程序员编写更精美的代码，那会更好。

首先没有人会强迫任何人使用C ++。如果该语言不适合您，则请使用另一种语言-有许多语言标为“不含C的C ++”。

C ++设计哲学是让程序员决定。如果他们想用脚拍自己的脚，那就放手。这样可以完成许多不好的事情，但是也可以提供很大的灵活性。例如，Boost不太可能以Java之类的语言编写，因为它利用了通常回避的语言功能和做法。C ++不可能像现在这样发展壮大-访问庞大的C库是一个巨大的优势，无论是接受还是放弃。

C ++与C的兼容性绝对是它的弱点之一，但也要记住，它是C的最大缺点之一。

我将添加乔恩·珀迪的精彩引文，我认为这是非常相关的：

一切都归结为实用主义与优雅，对我而言，尽管我对精确，优美的代码很着迷，但编写一个丑陋的程序要好于编写一个无所事事的漂亮程序。

删除混合动力车可能会提高美观度，但会影响功能。

如果委员会试图强迫人们使用一种更优雅的语言（有人的想法），那么它可能会被忽略。人们将继续做他们想做的事情，编译器供应商将紧随市场（但是编译器供应商在委员会中有足够的代表权来阻止这种情况）。

无论如何，您提倡的大部分内容实际上都是基于问题域的判断问题。许多小程序根本不需要（例如）命名空间。当我编写一个30行的文本过滤器时，试图强迫我使用名称空间将是愚蠢而自大的。即使您决定只在X行以上的代码，Y函数或涉及的任何内容上应用它，但通常仍然适得其反。命名空间的设计是出于某种原因，以防止/解决特定问题。试图在没有这些问题的情况下强制使用它们对任何人都无济于事。

同时，我认为值得一提的是，相当多的人确实花了很多时间和精力来尝试不仅实现C ++的优雅，而且教导和引导人们使用这些功能编写更好的代码（例如，许多Boost贡献者）。因此，那些继续坚持将代码编写为“带类C”的人们几乎忽略了那里的内容。我认为他们会像无视新编译器一样自在，就像他们无视过去十年或更长时间里关于如何使用C ++的一切知识一样（例如，Modern C ++ Design于11年前发布，但是大多数人您正在谈论的内容显然还没有听说过，即使是最简单的部分，也很少阅读或理解。

您的想法构成了Java背后的大部分设计原理。Java迫使您使用类，根据包层次结构组织文件层次结构，捕获异常等。人们仍然设法在其中编写类似C的代码。

作为程序员，我们有时会忘记最好的解决方案可能不是技术解决方案。在这种情况下，同行评审是最著名的解决方案。

C ++没有“一种正确的方法”；每种方法都有优点和缺点。解决方案可以用一百种不同的方式编写。

作为软件开发人员，您必须决定哪种方法最适合手头的任务。

我认为您列出的所有内容都是可选的，这会带来更多而不是更少的优雅。不必要使用的功能在我眼中微不足道。

我们需要使用编程解决的问题非常不同。
有些使用OO原理可以很好地解决（例如GUI），有些则更适合纯粹的功能性处理（例如，数字化的东西），而有些则最好用低级的“接近硅”语言来表示。

许多软件都需要解决子问题，而这些子问题可以用任何一种方法来最好地解决。将解决方案强制为特定形式只会导致代码不符合其目的（您甚至可能会说“不太优雅”）。

这也是为什么C ++混合岬是一个很好的事情-它让我们解决问题繁多的方式，适合的问题，而不是当前的教条。
当然，它可能会被误用-每当您有一件柔软的东西时，都有可能以一种不好的方式弯曲它-但优雅来自于认真的思考和经验，而不是来自对时尚的热爱。