全局分析

 【P&S 94】中提到對于類型安全的檢測來說有兩種假設。一種是封閉式環境下的假設，此時程序中的各個部分在編譯期間就能被確定，然后我們可以對于整個程序來進行類型檢測。另一種是開放式環境下的假設，此時對于類型的檢測是在單獨的模塊中進行的。對于實際開發和建立原型來說，第二種假設顯得十分有效。然而，【P&S 94】中又提到，“當一種已經完成的軟件產品到達了成熟期時，采用封閉式環境下的假設就可以被考慮了，因為這樣可以使得一些比較高級的編譯技術得以有了用武之處。只有在整個程序都被了解的情況下，我們才可能在其上面執行諸如全局寄存器分配、程序流程分析及無效代碼檢測等動作。”（附：【P&S 94】Jens Palsberg and Michael I. Schwartzbach, Object-Oriented Type Systems, Wiley 1994）
 
 C++中的一個主要問題就是：對于程序的分析過程被編譯器（工作于開放式環境下的假設）和鏈接器（依賴于十分有限的封閉式環境下的分析）給劃分開了。封閉式環境下的或是全局的分析被采用的實質原因有兩個方面：首先，它可以保證匯編系統的一致性；其次，它通過提供自動優化，減輕了程序員的負擔。
 
 程序員能夠被減輕的主要負擔是：設計父類的程序員不再需要(不得不)通過利用虛擬函數的修飾成份（virtual），來協助編譯器建立起vtable。正如我們在“虛擬函數”中所說，這樣做將會影響到軟件的彈性。Vtable不應該在一個單獨的類被編譯時就被建立起來，最好是在整個系統被裝配在一起時一并被建立。在系統被裝配（鏈接）時期，編譯器和鏈接器協同起來，就可以完全決定一個函數是否需要在vtable中占有一席之地。除上述之外，程序員還可以自由地使用在其他模塊中定義的一些在本地不可見的信息；并且程序員不再需要維護頭文件的存在了。
 
 在Eiffel和Object Pascal中，全局分析被應用于整個系統中，決定真正的多態性的函數調用，并且構造所需的vtable。在Eiffel中，這些是由編譯器完成的。在 Object Pascal中，Apple擴展了鏈接器的功能，使之具有全局分析的能力。這樣的全局分析在C/Unix環境下很難被實現，所以在C++中，它也沒有被包含進去，使得負擔被留給了程序員。
 
 為了將這個負擔從程序員身上移除，我們應該將全局分析的功能內置于鏈接器中。然而，由于C++一開始的版本是作為一個Cfront預處理器實現的，對于鏈接器所做的任何必要的改動不能得到保證。C++的最初實現版本看起來就像一個拼湊起來的東西，到處充滿著漏洞。C++的設計嚴格地受限于其實現技術，而不是其他（例如沒有采用好的程序語言設計原理等），因為那樣就需要新的編譯器和鏈接器了。也就是說，現在的C++發展嚴格地受限于其最初的試驗性質的產品。
 
 我現在確信這種技術上的依賴關系（即C++ 依賴于早先的C）嚴重地損害了C++，使之不是一個完整意義上的面向對象的高級語言。一個高級語言可以將簿記工作從程序員身上接手過去，交給編譯器去完成，這也是高級語言的主要目的。缺乏全局（或是封閉式環境下的）分析是C++的一個主要不足，這使得C++在和Eiffel之類的語言相比時顯得十分地不足。由于Eiffel堅持系統層次上的有效性及全局分析，這意味著Eiffel要比C++顯得有雄心多了，但這也是Eiffel產品為什么出現地這么緩慢的主要原因。
 
 Java只有在需要時才動態地載入軟件的部分，并將它們鏈接起來成為一個可以運行的系統。也因而使得靜態的編譯期間的全局分析變成不可能的了（因為Java被設計成為一個動態的語言）。然而，Java假設所有的方法都是virtual的，這也就是為什么Java和 Eiffel是完全不同的工具的一個原因。關于Eiffel，可以參見于Dynamic Linking in Eiffel(DLE)。