1.12.2　管理的障碍

如果我们是经理，我们的工作是为项目组争取资源，搬除通往胜利道路上的障碍，并且通常要努力提供更高的生产效率和和谐的环境，使项目组更有可能产生奇迹。转向C++的三类方式，如果不花费任何代价都是不可能的。与C程序员（也可能是其他过程型语言的程序员）项目组的OOP替代品相比，虽然转向C++可能更便宜一些（这取决于约束条件）^[1]，但并不是免费的，在试图说服公司转向C++并对转移投资之前，我们应当知道会有障碍。

1.12.2.1　启动的代价

转移到C++的代价比获得C++编译器（最好的编辑器之一，GNU C++编译器，是免费的）大得多。进行培训（也可能是第一个项目的指导），并且确定和购买解决问题的类库而不是自己开发，那么中长期的代价就将减小。这种直接的经费开支是实际建议所必须考虑的因素。另外还有隐藏的花费，在于学习新语言和新程序设计环境期间的生产效率下降。培训和指导确实能减少花费，但是项目组成员必须自己克服了解新技术的各种困难。在这个过程中，将犯更多错误（这是特点，因为认识错误是学习的最快途径），生产效率下降。尽管如此，对于一些类型的程序设计问题，有了正确的类和正确的开发环境，C++学习时可能会比继续用C语言有更高的生产效率（即便考虑到程序员正在犯更多的错误和每天写更少的代码行）。

1.12.2.2　性能问题

一个普遍的问题是，“OOP不会自动使得我们的程序变大和变慢吗？”回答是“不一定”。大多数传统的OOP语言是以实验和快速原型方法设计的，这样实际上就决定了其在规模上的扩大和在速度上的下降。然而，C++是以生产性程序的方式设计的。当用快速原型方式时，我们能尽可能快地将构件组合在一起，而忽视效率问题。如果使用了第三方库，通常已经由它们的厂商优化过了，在这种情况下，用快速开发方法，效率也不是问题。如果我们有一个喜欢的系统，它足够小和快，就继续使用，如果不是，就调整，用描述工具（profiling tool），首先改进速度。这可用简单的C++内部功能完成。如果无效，就寻找对底层实现的修改，但要做到不改变所需要的特殊类。只有当全都不能解决问题时，才需要改变设计。性能在设计中的地位很重要，是主要的设计标准之一。运用快速原型法，可以尽早地了解系统性能。

如前所述，在C和C++之间的规模和速度之比常常不同，但一般是10%之内，而且通常更接近。当使用C++代替C时，可能在规模和速度上得到大的改进，因为为C++所做的设计很大程度上不同于为C所做的。

在C和C++之间比较规模和速度的证据至今还只是传说性的估计，也许还会继续如此。尽管有一些人建议对相同的项目用C和C++同时做，但也许不会有公司把钱浪费在这里，除非它非常大并且对这个研究项目感兴趣。即便如此，它也希望钱花得更好。已经从C（或其他过程型语言）转到C++（或一些其他OOP语言）的程序员几乎一致地都有在程序设计效率上得到很大提高的个人经验，这是能找到的最引人注目的证据。

1.12.2.3　常见的设计错误

当项目组开始使用OOP和C++时，程序员们将会出现一系列常见的设计错误。这经常会发生，因为在早期项目的设计和实现过程中从专家们那里得到的反馈太少，在公司中没有专家，而聘请顾问可能有阻力。我们可能会觉得，在这个周期中，我们懂得OOP太早了并开始了一条不好的道路。有时，对于在这个语言上有经验的一些人而言，显而易见的问题可能是新手们在内部的激烈争论。大量的这类问题都能通过聘用外部富有经验的专家培训和指导来避免。

另一方面，容易出现设计错误的事实也反映出C++的主要缺点：对C向后兼容（当然，这也是它的主要优势）。为了完成能编译C代码的任务，C++不得不做一些妥协，这形成了一些“死角”。这些都是事实，并且包含了学习这个语言的大量弯路。在本书和后续的卷（以及其他书，参看附录C）中，试图揭示当使用C++时会遇到的大量陷阱。应当知道，在这个安全网中有一些漏洞。

[1]因为生产效率的改进，所以Java语言也应当被考虑。