保證類型安全的聯(lián)結(jié)屬性（type-safe linkage）
C++ARM中解釋說type-safe linkage并不能100%的保證類型安全。既然它不那100%的保證類型安全，那么它就肯定是不安全的。統(tǒng)計分析顯示：即便在很苛刻的情況下，C++ 出現(xiàn)單獨(dú)的O-ring錯誤的可能性也只有0.3%。但我們一旦將6種這樣的可能導(dǎo)致出錯的情況聯(lián)合起來放在一起，出錯的幾率就變得大為可觀了。在軟件中，我們經(jīng)常能夠看到一些錯誤的起因就是其怪異的聯(lián)合。OO的一個主要目的就是要減少這種奇怪的聯(lián)合出現(xiàn)。
大多數(shù)問題的起因都是一些難以察覺的錯誤，而不是那些簡單明了的錯誤導(dǎo)致問題的產(chǎn)生。而且在通常的情況下，不到真正的臨界時期，這樣的錯誤一般都很難被檢測到，但我們不能由此就低估了這種情況的嚴(yán)肅性。有許多的計劃都依賴于其操作的正確性，如太空計劃、財政結(jié)算等。在這些計劃中采用不安全的解決方案是一種不負(fù)責(zé)任的做法，我們應(yīng)該嚴(yán)厲禁止類似情況的出現(xiàn)。
C++在type-safe linkage上相對于C來說有了巨大的進(jìn)步。在C中，鏈接器可以將一個帶有參數(shù)的諸如f(p1,...)這樣的函數(shù)鏈接到任意的函數(shù)f()上面，而這個 f()甚至可以沒有參數(shù)或是帶有不同的參數(shù)都行。這將會導(dǎo)致程序在運(yùn)行時出錯。由于C++的type-safe linkage機(jī)制是一種在鏈接器上實(shí)做的技巧，對于這樣的不一致性，C++將統(tǒng)統(tǒng)拒絕。
C++ARM將這樣的情況概括如下－－“處理所有的不一致性->這將使得C++得以100%的保證類型安全->這將要求對鏈接器的支持或是機(jī)制（環(huán)境）能夠允許編譯器訪問在其他編譯單元里面的信息”。
那么為什么市面上的C++編譯器（至少AT&T的是如此）不提供訪問其他畢業(yè)單元中的信息的能力呢？為什么到現(xiàn)在也沒有一種特殊的專門為C++設(shè)計的鏈接器出現(xiàn)，可以100%的保證類型安全呢？答案是C++缺乏一種全局分析的能力（在上一節(jié)中我們討論過）。另外，在已有的程序組件外構(gòu)造我們的系統(tǒng)已經(jīng)是一種通用的Unix軟件開發(fā)方式，這實(shí)現(xiàn)了一定的重用，然而它并不能為面向?qū)ο蠓绞降闹赜锰峁┱嬲膹椥约耙恢滦浴?br>
在將來， Unix可能會被面向?qū)ο蟮牟僮飨到y(tǒng)給替代，這樣的操作系統(tǒng)足夠的“開放”并且能夠被合適地裁剪用以符合我們的需求。通過使用管道(pipe)及標(biāo)志 (flag)，Unix下的軟件組件可以被重復(fù)利用以提供所需的近似功能。這種方法在一定的情況下行之有效，并且頗負(fù)效率（如小型的內(nèi)部應(yīng)用，或是用以進(jìn)行快速原型研究），但對于大規(guī)模、昂貴的、或是對于安全性要求很高的應(yīng)用來說，采取這樣的開發(fā)方法就不再適合了。在過去的十年中，集成的軟件（即不采用外部組件開發(fā)的軟件）的優(yōu)點(diǎn)已經(jīng)得到了認(rèn)同。傳統(tǒng)的Unix系統(tǒng)不能提供這樣的優(yōu)點(diǎn)。相比而言，集成的系統(tǒng)更加的復(fù)雜，對于開發(fā)它們的開發(fā)人員有著更多的要求，但是最終用戶(end user)要求的就是這樣的軟件。將所有的東西拙劣的放置于一起構(gòu)成的系統(tǒng)是不可接受的。現(xiàn)在，軟件開發(fā)的重心已經(jīng)轉(zhuǎn)到組件式軟件開發(fā)上面來了，如公共領(lǐng)域的OpenDoc或是Microsoft的OLE。
對于鏈接來說，更進(jìn)一步的問題出現(xiàn)在：不同的編譯單元和鏈接系統(tǒng)可能會使用不同的名字編碼方式。這個問題和type-safe linkage有關(guān)，不過我們將會在“重用性及兼容性”這節(jié)講述之。
Java使用了一種不同的動態(tài)鏈接機(jī)制，這種機(jī)制被設(shè)計的很好，沒有使用到Unix的鏈接器。Eiffel則不依賴于Unix或是其他平臺上的鏈接器來檢測這些問題，一切都由編譯器完成。
Eiffel 定義了一種系統(tǒng)層上的有效性（system-level validity）。一個Eiffel編譯器也就因此需要進(jìn)行封閉環(huán)境下的分析，而不是依賴于鏈接器上的技巧。你也可以就此認(rèn)為Eiffel程序能夠保證 100%的類型安全。對于Eiffel來說有一個缺點(diǎn)就是，編譯器需要干的事情太多了。（通常我們會說的是它太“慢”了，但這不夠精確）目前我們可以通過對于Eiffel提供一定的擴(kuò)展來解決這個問題，如融冰技術(shù)(melting-ice technology)，它可以使得我們對于系統(tǒng)的改動和測試可以在不需要每次都進(jìn)行重新編譯的情況下進(jìn)行。
現(xiàn)在讓我們來概括一下前兩個小節(jié) － 有兩個原因使我們需要進(jìn)行全局（或封閉環(huán)境下的）分析：一致性檢測及優(yōu)化。這樣做可以減掉程序員身上大量的負(fù)擔(dān)，而缺乏它是C++中的一個很大的不足。