本文内容摘抄自C++经典书籍：《Thinking in C++》
操作概念：OOP程序像什么
我们已经知道，用C 语言编写的过程程序就是一些数据定义和函数调用。要理解这种程序的含义，程序员必须掌握函数调用和函数实现的本身。这就是过程程序需要中间表示的原因。中间表示容易引起混淆，因为中间表示的表述是原始的，更偏向于计算机，而不偏向于所解决的问题。
因为 C++ 向 C 语言增加了许多新概念，所以程序员很自然地认为，C + +程序中的m a i n ( )会比功能相同的 C 程序更复杂。
但令人吃惊的是，一个写得很好的C + +程序一般要比功能相同的C程序更简单和容易理解。程序员只会看到一些描述问题空间对象的定义（而不是计算机的描述），发送给这些对象的消息。这些消息表示了在这个空间的活动。
面向对象程序设计的优点之一是通过阅读，很容易理解代码。通常，面向对象程序需要较少的代码，因为问题中的许多部分都可以用已存在的库代码。
为什么C++会成功
C + +能够如此成功，部分原因是它的目标不只是为了将 C语言转变成O O P语言（虽然这是最初的目的），而且还为了解决当今程序员，特别是那些在 C语言中已经大量投资的程序员所面临的许多问题。
人们已经对O O P语言有了这样传统的看法：程序员应当抛弃所知道的每件事情并且从一组新概念和新文法重新开始，他应当相信，最好丢掉所有来自过程语言的老行装。从长远角度看，这是对的。但从短期角度看，这些行装还是有价值的。最有价值的可能不是那些已存在的代码库（给出合适的工具，可以转变它），而是已存在的头脑库。
作为一个职业 C程序员，如果让他丢掉他知道的关于 C的每一件事，以适应新的语言，那么，几个月内，他将毫无成果，直到他的头脑适应了这一新范例为止。如果他能调整已有的 C知识，并在这个基础上扩展，那么他就可以继续保持高效率，带着已有的知识，进入面向对象程序设计的世界。因为每个人有他自己的程序设计模型，所以这个转变是很混乱的。因此， C + +成功的原因是经济上的：转变到O O P需要代价，而转变到C + +所花的代价较小。
C + +的目的是提高效率。效率取决于很多东西，而语言是为了尽可能地帮助使用者，尽可能不用武断的规则或特殊的性能妨碍使用者。 C + +成功是因为它立足于实际：尽可能地为程序员提供最大便利。
较好的C
即便程序员在C + +环境下继续写C代码，也能直接得到好处，因为C + +堵塞了C语言中的一些漏洞，并提供更好的类型检查和编译时的分析。程序员必须先说明函数，使编译器能检查它们的使用情况。预处理器虚拟删除值替换和宏，这就减少了查找疵点的困难。C + +有一个性能，称为r e f e r e n c e s (引用)，它允许对函数参数和返回值的地址进行更方便的处理。函数重载改进了对名字的处理，使程序员能对不同的函数使用相同的名字。另外，名字空间也加强了名字的控
制。许多性能使C的更安全。
采用渐进的学习方式
与学习新语言有关的问题是效率的问题。所有公司都不可避免地因软件工程师学习新语言而突然降低了效率。C + +是对C的扩充，而不是新的文法和新的程序设计模型。程序员学习和理解这些性能，逐渐应用并继续创建有用的代码。这是 C + +成功的最重要的原因之一。
另外，已有的C代码在C + +中仍然是有用的，但因为 C + +编译器更严格，所以，重新编译这些代码时，常常会发现隐藏的错误。
运行效率
有时，以程序执行速度换取程序员的效率是值得的。假如一个金融模型仅在短期内有用，那么快速创建这个模型比所写程序能更快速执行重要。很多应用程序都要求有一定的运行效率，所以C + +在更高运行效率时总是犯错。 C程序员非常重视运行效率，这让他们认为这个语言不太庞大，也不太慢。产生的代码运行效率不够时，程序员可以用 C + +的一些性能做一些调整。
C + +不仅有与C相同的基本控制能力（和C + +程序中直接写汇编语言的能力），非正式的证据指出，面向对象的C + +程序的速度与用C写的程序速度相差在±1 0 %之内，而且常常更接近。用O O P方法设计的程序可能比C的对应版本更有效。
系统更容易表达和理解
为适合于某问题而设计的类当然能更好地表达这个问题。这意味着写代码时，程序员是在用问题空间的术语描述问题的解（例如“把锁链放在箱子里”），而不是用计算机的术语，也就是解空间的术语，描述问题的解（例如“设置芯片的一位即合上继电器”）。程序员所涉及的是较高层的概念，一行代码能做更多的事情。
易于表达所带来的另一个好处是易于维护。据报道，在程序的整个生命周期中，维护占了花费的很大部分。如果程序容易理解，那么它就更容易维护，还能减少创建和维护文档的花费。
“库”使你事半功倍
创建程序的最快方法是使用已经写好的代码：库。 C + +的主要目标是让程序员能更容易地使用库，这是通过将库转换为新数据类型（类）来完成的。引入一个库，就是向该语言增加一个新类型。编译器负责这个库如何使用，保证适当的初始化和清除，保证函数被正确地调用，因此程序员的精力可以集中在他想要这个库做什么，而不是如何做上。
因为程序的各部分之间名字是隔离的，所以程序员想用多少库就用多少库，不会有像 C语言那样的名字冲突。
• 模板的源代码重用
一些重要的类型要求修改源代码以便有效地重用。模板可以自动完成对代码的修改，因而是重用库代码特别有用的工具。用模板设计的类型很容易与其他类型一起工作。因为模板对程序员隐藏了这类代码重用的复杂性，所以特别好用。
错误处理
在C语言中，错误处理声名狼藉。程序员常常忽视它们，对它们束手无策。如果正在建大而复杂的程序，没有什么比让错误隐藏在某处，且不能指出它来自何处更糟的了。 C + +的异常处理（见第1 7章的内容）保证能检查到错误并进行处理。
大程序设计
许多传统语言对程序的规模和复杂性有自身的限制。例如， B A S I C对于某些类型的问题能很快解决，但是如果这个程序有几页纸长，或者超出该语言的正常解题范围，那么它可能永远算不出结果。C语言同样有这样的限制，例如当程序超过 50 000行时，名字冲突就开始成为问题。简言之，程序员用光了函数和变量名。另一个特别糟糕的问题是如果 C语言中存在一些小漏洞 — 错误藏在大程序中，要找出它们是极其困难的。
没有清楚的文字告诉程序员，什么时候他的语言会失效，即便有，他也会忽视它们。他不说“我的B A S I C程序太大，我必须用 C重写”，而是试图硬塞进另外几行，增加额外的性能。所以额外的花费就悄悄增加了。
设计C + +的目的是为了辅助大程序设计，也就是说，去掉小程序和大程序之间复杂性的分界。当程序员写h e l l o - w o r l d类实用程序时，他确实不需要用O O P、模板、名字空间和异常处理，但当他需要的时候，这些性能就有用了。而且，编译器在排除错误方面，对于小程序和大程序一样有效。
http://blog.csdn.net/rl529014/article/details/51921883