轉自：http://hi.baidu.com/chenfalei/blog/item/f33ac0133500ac21dd540186.html

程式語言的最終夢想：靜態型別安全

常聽人說“強型別”。但個人對強型別都有不同的理解。

有的認為C++就是強型別，有的認為C也是強型別。因為它們都有型別檢查。

可見，如果沒有一個明確的定義，談“強型別”不免是自說自話。

那麼，可以給“強型別”下一個什麼樣的定義呢？

最原始的定義是這樣： 靜態型別系統將檢查所有的錯誤。只要通過了靜態型別檢查，程式將不會有bug.

但是，明顯這是不現實的，因為有些bug是純粹邏輯上的。比如說：

print "hell world"

少打了一個o, 是bug, 但除非把自然語言識別加進來，計算機對此無能為力。

於是，我們把強型別定義為：

靜態型別系統檢查所有型別匹配的錯誤，只要通過了型別檢查，就保證不會有把蘋果當成汽油的事發生。

至於型別匹配錯誤，我們把它定義成：

當你試圖把一個變數當作型別A來處理時，卻意外發現它不是型別A的。它可能是型別B的，也可能什麼都不是。

再謹慎一點，我們可以排除掉使用downcast的情況。如果你非要

(汽油）new 蘋果（）， 自己找死，我們也管不著了。

這可以說是所有支援型別的語言所追求的最高境界。想想吧，一旦你的程式通過編譯，不管它有幾百萬行，你都可以自信地說：我的程式裡面最多隻有邏輯錯誤了。

多好啊！！！

那麼，有什麼語言達到了這個要求呢？C嗎？C++嗎？ Java嗎？

不幸的是，它們都不是。

先說C,

union大家都熟悉吧？你把兩種不同的型別混雜於一塊記憶體空間。然後用一個變數來標識它的真正型別。

但是，如果你的程式一旦錯誤地把型別A當成型別B, 編譯器不會警告你的。

還有，char* p = "hello world";

這句話，也不是型別安全的。你如果做p[0]='x'; 編譯器不會抱錯，因為p的型別是char*, 而對char* 做下標操作是完全合法的。

C還有好多其它不嚴格的地方。

C++呢？上面提到的兩個C的問題它同樣有。

還有一些不那麼明顯的型別漏洞。

1。 placement new. 看這個程式碼：

X* px = new X();

new (px) Y();

px->m();

這裡，編譯器不會報錯，但px->m()的結果卻是未知的。

有人解釋說：這是因為px指向的物件已經不存在了。但是，我們不是研究它為什麼失敗，你可以有一千個理由解釋你的程式為什麼崩潰，但是，事實很簡單：它崩潰了。因為你想把一個不是X的東東當成X來使用。

2。delete p;

很驚訝是嗎？

X* px = new X();

delete px;

px->m();

簡簡單單地就繞過了編譯器，得到了一個型別匹配錯誤。你也可以較它懸掛指標錯誤，但是，根據我們對型別匹配錯誤的定義，我們想把px當成X*, 但實際上它並不是我們期望的型別，所以，它也是型別錯誤的一種。否則，不免對其他的型別漏洞不夠公平，

你這個px->m()並不必例子一里的px->m()安全一丁點。 為什麼我是型別錯誤，你就不是？

再看Java, 相比於C/C++, Java在型別安全上有了長足的進步。上面提到的問題，在Java裡全都不存在了。Java徹底地扔掉了union, 扔掉了指標，這些設計在效率上可能值的探討。但是，一個明顯的事實是，它的型別系統更安全了。

Java採用了垃圾收集機制。這對很多習慣於又程式管理記憶體的C/C++程式設計師來說是有爭議的。但是，如果不考慮效率等問題，只從型別安全的角度去看，它免除了delete帶來的型別安全漏洞，朝真正意義上的靜態型別安全又近了一步。

不過，Java也不是完整的靜態型別安全。

缺乏泛形的支援，只是程式設計師要頻繁地做類似(蘋果)obj;這樣的downcast. 大大地加大了程式的隱患。好在java也認識到這一點，各種不同的努力都在試圖往java中加入generics. 不過，這不是本文要討論的目的，而且，畢竟，我們的前提是不考慮downcast.

那麼，不用downcast, java程式就是靜態型別安全的嗎?

請看這段程式碼：

String[] sa = new String[100];

sa[0] = "hello world";

Object[] oa = sa;

oa[0] = new Integer(1);

System.out.println(sa[0]);

通！火藥桶爆炸了！

究其原因，是在於Object[] oa = sa;這一句。

根據型別理論裡的協變原理，只有只讀的Object[] 才能是String[]的父型別。但Java裡並沒有只讀陣列這麼個型別，悲劇就這樣發生了。

同樣的隱患也存在於一些泛形的語言之中。如果語言想提供協變的支援，如，想讓MyTemplate< Object> 是MyTemplate<String>的父型別，那麼，Object型別的引用在MyTemplate的定義中也不能是隨意的。它必須符合 協變的規定，只處於協變的位置上。

還有一個靜態型別系統無能為力的地方，如：

String s[] = new String[2];

s[2] = "hello world";

砰！悲劇再次發生了。.

它符合我們對類析匹配錯誤的定義：你試圖把s[2]當作String來處理，但實際上它不是。

這個問題存在於幾乎各種支援陣列的語言。

因為陣列的的長度可以是任意的，很難設計一個型別系統來靜態保證陣列的邊界不會被越過。

Pascal試圖這樣做，它通過在型別上附加陣列的長度來幫助靜態型別系統工作。

但是，一個規定了大小的陣列雖然可以保證型別安全，可因為不同大小的陣列不能互相轉換，大大犧牲了程式的靈活性。

Java的解決方案很現實：既然這樣做不好做，那就算了吧。我在執行時加入邊界檢查，雖然不能靜態地保證陣列的邊界 安全，至少可以保證不出大漏子。 其實，理論上說，Java的做法是通過改變陣列的動態語義，把一個未定義的型別匹配錯誤轉換成了一個相對安全的定義好的物件狀態錯誤。

是啊，哪有十全十美的事情呢？畢竟，程式作為一個狀態機，總是會有非法狀態的。

其實，也還是有另一種方案的。

ML, 這個程式語言界的老前輩。幾乎是帶型別的functional language的開山祖師了。

它的方案是什麼？

簡單， 不能再簡單了，那就是：乾脆不要陣列！

聽起來嚇人，但是，這是和functional language的方針一致的，因為陣列是一個要求副作用的資料結構，而functional是要摒棄副作用，所以，functional棄用陣列也是很 自然的。（具有諷刺意味的是，ML的一些擴充套件還是把陣列加了進來，因為陣列是實現象hash table之類的資料結構的必經之路。）

說了這麼多，基本上把可能的型別系統漏洞都從陰溝裡翻了出來， 晒晒太陽。

C#怎麼樣？ 我只是對C#驚鴻一瞥，當時看看，現在許久不用，都忘掉了。不過，這個陣列越界的問題，相信仍然存在。

如果我們現實一點，把陣列越界這個不大可能根本解決的問題拋開，那麼，唯一讓我對C#擔心的，就是這個陣列的協變問題了