C++的不足之处讨论系列（三）

 C++的不足之处讨论系列（三）
保证类型安全的联结属性（type-safe linkage）
C++ARM中解释说type-safe linkage并不能100%的保证类型安全。既然它不那100%的保证
类型安全，那么它就肯定是不安全的。统计分析显示：即便在很苛刻的情况下，C++出现
单独的O-ring错误的可能性也只有0.3%。但我们一旦将6种这样的可能导致出错的情况联
合起来放在一起，出错的几率就变得大为可观了。在软件中，我们经常能够看到一些错
误的起因就是其怪异的联合。OO的一个主要目的就是要减少这种奇怪的联合出现。
大多数问题的起因都是一些难以察觉的错误，而不是那些简单明了的错误导致问题的产
生。而且在通常的情况下，不到真正的临界时期，这样的错误一般都很难被检测到，但
我们不能由此就低估了这种情况的严肃性。有许多的计划都依赖于其操作的正确性，如
太空计划、财政结算等。在这些计划中采用不安全的解决方案是一种不负责任的做法，
我们应该严厉禁止类似情况的出现。
C++在type-safe linkage上相对于C来说有了巨大的进步。在C中，链接器可以将一个带
有参数的诸如f(p1,...)这样的函数链接到任意的函数f()上面，而这个f()甚至可以没有
参数或是带有不同的参数都行。这将会导致程序在运行时出错。由于C++的type-safe
linkage机制是一种在链接器上实做的技巧，对于这样的不一致性，C++将统统拒绝。
C++ARM将这样的情况概括如下－－"处理所有的不一致性->;这将使得C++得以100%的保证
类型安全->;这将要求对链接器的支持或是机制（环境）能够允许编译器访问在其他编译
单元里面的信息"。
那么为什么市面上的C++编译器（至少AT&T的是如此）不提供访问其他毕业单元中的信息
的能力呢？为什么到现在也没有一种特殊的专门为C++设计的链接器出现，可以100%的保
证类型安全呢？答案是C++缺乏一种全局分析的能力（在上一节中我们讨论过）。另外，
在已有的程序组件外构造我们的系统已经是一种通用的Unix软件开发方式，这实现了一
定的重用，然而它并不能为面向对象方式的重用提供真正的弹性及一致性。
在将来，Unix可能会被面向对象的操作系统给替代，这样的操作系统足够的"开放"并且
能够被合适地裁剪用以符合我们的需求。通过使用管道(pipe)及标志(flag)，Unix下的
软件组件可以被重复利用以提供所需的近似功能。这种方法在一定的情况下行之有效，
并且颇负效率（如小型的内部应用，或是用以进行快速原型研究），但对于大规模、昂
贵的、或是对于安全性要求很高的应用来说，采取这样的开发方法就不再适合了。在过
去的十年中，集成的软件（即不采用外部组件开发的软件）的优点已经得到了认同。传
统的Unix系统不能提供这样的优点。相比而言，集成的系统更加的复杂，对于开发它们
的开发人员有着更多的要求，但是最终用户(end user)要求的就是这样的软件。将所有
的东西拙劣的放置于一起构成的系统是不可接受的。现在，软件开发的重心已经转到组
件式软件开发上面来了，如公共领域的OpenDoc或是Microsoft的OLE。
对于链接来说，更进一步的问题出现在：不同的编译单元和链接系统可能会使用不同的
名字编码方式。这个问题和type-safe linkage有关，不过我们将会在"重用性及兼容性"
这节讲述之。
Java使用了一种不同的动态链接机制，这种机制被设计的很好，没有使用到Unix的链接
器。Eiffel则不依赖于Unix或是其他平台上的链接器来检测这些问题，一切都由编译器
完成。
Eiffel定义了一种系统层上的有效性（system-level validity）。一个Eiffel编译器也
就因此需要进行封闭环境下的分析，而不是依赖于链接器上的技巧。你也可以就此认为E
iffel程序能够保证100%的类型安全。对于Eiffel来说有一个缺点就是，编译器需要干的
事情太多了。（通常我们会说的是它太"慢"了，但这不够精确）目前我们可以通过对于E
iffel提供一定的扩展来解决这个问题，如融冰技术(melting-ice technology)，它可以
使得我们对于系统的改动和测试可以在不需要每次都进行重新编译的情况下进行。
现在让我们来概括一下前两个小节 － 有两个原因使我们需要进行全局（或封闭环境下
的）分析：一致性检测及优化。这样做可以减掉程序员身上大量的负担，而缺乏它是C++
中的一个很大的不足。