以下文章翻译自Ian Joyner所著的
《C++?? A Critique of C++ and Programming and Language Trends of the 1990s》 3/E【Ian Joyner 1996】
原著版权属于Ian Joyner，征得Ian Joyner本人的同意，我得以将该文翻译成中文。因此，本文的中文版权应该属于我;-)
该文章的英文及中文版本都用于非商业用途，你可以随意地复制和转贴它。不过最好请在转贴时加上前面的这段声明。
如果有人或机构想要出版该文，请最好联系原著版权所有人及我。
另外，该篇文章已经包含在Ian Joyner所写的《Objects Unencapsulated 》一书中（目前已经有了日文的翻译版本）,该书的介绍可参见于：
http://www.prenhall.com/allbooks/ptr_0130142697.html
http://efsa.sourceforge.net/cgi-bin/view/Main/ObjectsUnencapsulated
http://www.accu.org/bookreviews/public/reviews/o/o002284.htm
Ian Joyner的联系方式：
我的联系方式：
译者前言：
要想彻底的掌握一种语言，不但需要知道它的长处有哪些，而且需要知道它的不足之处又有哪些。这样我们才能用好这门语言，避免踏入语言中的一些陷阱，更好地利用这门语言来为我们的工作所服务。
Ian Joyner的这篇文章以及他所著的《Objects Unencapsulated 》一书中，向我们充分的展示了C++的一些不足之处，我们应该充分借鉴于他已经完成的伟大工作，更好的了解C++，从而写出更加安全的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编译器也就因此需要进行封闭环境下的分析，而不是依赖于链接器上的技巧。你也可以就此认为Eiffel程序能够保证100%的类型安全。对于Eiffel来说有一个缺点就是，编译器需要干的事情太多了。（通常我们会说的是它太“慢”了，但这不够精确）目前我们可以通过对于Eiffel提供一定的扩展来解决这个问题，如融冰技术(melting-ice technology)，它可以使得我们对于系统的改动和测试可以在不需要每次都进行重新编译的情况下进行。
现在让我们来概括一下前两个小节 － 有两个原因使我们需要进行全局（或封闭环境下的）分析：一致性检测及优化。这样做可以减掉程序员身上大量的负担，而缺乏它是C++中的一个很大的不足。
