被误解的C++

转载：http://www.gztarena.com
    回过头看看编程语言的发展，从最初没有语言，到机器语言和汇编语言，编程一直是专家的工作，语言也是少数精英的专有品。随后高级语言出现，人们可以用近似人话的东西指挥计算机。C语言的出现，使得系统编程有了非常合适的工具。同时，人们也发现C语言同样也能用于其他类型的开发。于是，C语言成了应用最广的语言。然而，人的本性促使人们对于C语言的很多缺陷产生不满，诸如抽象能力不足、资源管理困难等等。为此，C++被发明了，人们获得了C语言一样的灵活性，也获得了更强大的抽象能力。但是，就像大革命后的民众一样，人们对于C++的复杂性表达出不满。人们开始畏惧原先热心追捧的OOP、模板等等。有的人试图回复到C，那种简单的自由；有的人则追随Java等，试图通过抛弃灵活和自由，来换回简单。

    对于限制和自由，简单和复杂，实际上是你中有我，我中有你。限制有时也会提供一些自由，比如强类型化，是一种限制，但强类型却能阻止我们进行错误的类型转换，从而使得我们在使用类型和类型的对象时，不必如履薄冰。
再比如，C++中的类型转换操作符，在默认情况下执行隐式的类型转换：
class X
{
public:
operator int();
…
};
X x;
…
int a, b, c;
int a=b+x; //由于疏忽，c错打成了x（在键盘上它们相邻）。这里没有编译错误。

    C++提供这种操作符，则提供了一个类向另一种类型的转换的自由，但却很容易造成难以发现的错误，使得我们类型转换操作符的使用受到很大的限制。

    同样，简单和复杂也总是辩证的。有时复杂会造成简单，而简单也会造成复杂。

    复杂造成简单的案例在C++中随处可见，最典型的当属STL。设计和开发STL运用了C++最复杂的特性，但却使我们得以以最简单的方式编程：
// in C
DIR*  dir = opendir(".");
if(NULL != dir)
{
  struct dirent*  de;
  for(; NULL != (de = readdir(dir)); )
  {
    struct stat st;
    if( 0 == stat(de->d_name, &st) &&
        S_IFREG == (st.st_mode & S_IFMT))
    {
      remove(de->d_name);
    }
  }
  closedir(dir);
}

// in C++
readdir_sequence entries(".", readdir_sequence::files);
std::for_each(entries.begin(), entries.end(), ::remove);

And it’s even simpler in C++09:
// in C++09
std::for_each(readdir_sequence(".", readdir_sequence::files), ::remove);

    C++只是这个震荡过程中的一个开拓者。未来肯定会有很多超越C++的语言出现。但是，技术的进步已经无法挽回，我们也无法倒退到史前时代，我们只能向前进。但我们必须记住的是，新的强大的语言，必须象C++一样同时兼顾性能和抽象，但却没有C++的缺陷。（这种语言不会是简单的，但不会象C++那样复杂，因为C++大多数复杂性都来源于它的缺陷。）。这种语言应当能够以接近数学的形式描述一个问题或算法（依赖于抽象），但却能最大限度地保证运行的效率（依赖于性能）。C++在这些方面做了很多尝试，而且相当成功。但也为此付出了巨大的代价：复杂性、缺陷、难学等等。但我们不能以此认为C++的路走错了，应该走回头路。我们所应该做的，是认清C++的优势和缺陷，汲取营养，为未来更完善的语言做好准备。（我想更完善的语言，不大会像C那样简陋，象Java那样愚钝吧。当然，也不会像C++那样复杂和充满缺陷）。或许真的没有哪种单一的语言能够达成这个目标，那也可以采用“语言族”的形式（就像自动步枪族那样），以一族具有共同语法基础、编程模型，但又有各自特长的语言共同实现这一理想。

    另外，我还想强调一点：如何看待复杂性和难学性。复杂性和难学性有很多的来源。有的来自能力的扩展，比如，一旦引入OOP，那么自然必须面对类、对象、成员、继承等等复杂的概念。这是必不可少的。如果认为这种复杂性和难学性应该消除的话，那么这就相当于认为我们应该放弃电而改用火把和蜡烛。

    另一些复杂性和难学性来源于语言的缺陷。这种复杂性是不应该存在的，是应该消灭的。当然这是做不到的。没有任何一种语言是完美的，没有缺陷的。我们应该以积极的姿态来看待语言。当我们一味地争论一种语言的什么什么不是，自然很难从中学到有用的东西，也更难从中获得好处。我们可以比较语言，但不应该争论语言。

    最后，请注意，所有争论语言的出发点通常都是狭隘的，局部的。C语言的程序员喜欢以底层开发的要求强调语言的特性；Java程序员则喜欢以高层的应用开发的要求来评价语言。但是，他们似乎喜欢把软件开发的范围圈定在各自工作的范围内，来阐述某某语言的不足。可软件开发真的只有这些吗？要么最高层，只追求软件组装的简便性；要么最底层，只追求直观的数据表达和运行性能？是否在存在一些领域，既需要很好的性能，但不一定像实时系统那样风驰电掣；又需要长期的综合开发效率，但不一定象单一项目那样只抓现钞？

    对于最后一个问题，我的答案是肯定的。诸如数据库服务器、各类应用服务器、搜索引擎、图像处理和视觉处理、操作系统的上层服务组件、数据分析和处理等等。这些领域的共同特性，都是既有很高的性能要求，满足苛刻的运行时间要求；又有足够复杂性，需要更强大的抽象能力来提高开发效率。而且，这些领域的软件都规模庞大，结构复杂。同时又需要长期发展，并且不断扩充，以获得更大的技术优势和市场优势。这样的软件项目实际上对开发语言的综合能力提出挑战。对语言运用成本的考核，不仅仅局限在单一周期的开发过程中，还需要包括所有迭代周期的总体成本。C++尽管算不上完美的语言，但却是在这些方面综合能力最强的语言。而对于这些项目而言，其高附加值足以抵消C++人员费用方面的成本。况且在充分运用C++的抽象能力后，可以获得最低的产品扩展成本，有利于产品长期的发展。

    如果仔细地考察一下业界，我们会发现，没有任何一家主流的厂商声称C++过时。表面上看，象Sun、ms等公司，似乎正在积极地“反C++”。但是，他们实际上却是C++的积极使用者。（象他们这么积极地使用，怎么才能让C++消亡啊）。他们都认真地开发出很好的C++编译器，同时都积极参与C++0x标准的创建。他们的表现给人以一种“生怕被落下”的感觉。这一方面是因为他们有大量的C++代码存在，另一方面他们也充分认识到C++在软件开发中的作用。更重要的是，他们把C++看作一种未来。Java和C#或许能够满足他们眼前的利益，但从长远来看，人们善变的需求和品位，使这些语言不足以长期维持地为他们提供统治地位。而未来的C++则不仅仅为他们提供一种很好的软件开发的工具，或许有可能使得他们借以牟取某种商业上的利益也未可知。

    C++有很好的基础（，所以未来有很大的扩展和改进余地。它的生命力是强大的和持久的。每种语言都将没落，现在我们不会看到C++的结局。

除了第一行是广告

这篇东西还真是说得挺在理的