首頁
中文書目錄
原文書目錄
 站內快速搜尋
資源中心
Book Series
Special Interest













■好消息,歐萊禮書籍已重新鋪貨至各大書局及網路書店,歡迎讀者選購       ■歡迎各院校採用歐萊禮書籍,學校團購請洽校園服務團隊

[技術短文]

語言、平台、程式庫


語言、平台、程式庫,這三者之間有很密切的關係。本文嘗試著以程式庫為中心,探討它們之間的現況。

語言與程式庫
語言通常會伴隨著程式庫,沒有程式庫的語言,差不多什麼程式都寫不出來。比方說,用 C 語言寫出一個印出 Hello 的小程式,你需要用到 stdio 的程式庫。用 Python 寫 GUI 程式,你需要 Tkinter 程式庫。

平台與程式庫
平台通常也會伴隨著程式庫,沒有程式庫的平台,等於是擺明了不希望別人開發此平台的程式。比方說,你想用 Visual C++ 6 開發 Windows 程式,你需要用到 GDI32 以及 USER32 或 MFC 等程式庫。寫 Mac OS 9 的程式,需要 Carbon 程式庫。

平台的程式庫 vs 語言的程式庫
在 A 平台上用 B 語言開發軟體,你會同時面對 A 平台的程式庫和 B 語言的程式庫,此二程式庫因為是不同廠商所提供的,所以可能無法百分之百契合,特別是牽涉到記憶體管理、資源管理、執行緒等和作業系統有密切關係的主題時。如果你想進行的某功能在 A 平台的程式庫和 B 語言的程式庫都有提供,那麼你應該使用 A 平台程式庫的版本,通常比較安全些。比方說,用 C 語言開發 Windows 平台的程式,如果你想配置記憶體,那麼你應該呼叫 Win32 API 的版本(比方說 GlobalAlloc()),而非 C 語言的版本(比方說 malloc())。

跨平台的程式庫
你為某平台所開發的程式,為什麼不能在別的平台上重新編譯之後就能執行?問題就出在平台的程式庫上。比方說,你用 C 語言搭配 C 的標準程式庫和 Win32 程式庫,在 Windows 平台上開發出一個簡報軟體 WeakPoint 2000;你將 WeakPoint 2000 的原始程式拿到 Linux 上編譯,卻無法編譯成功,問題就出在 Linux 沒有 Win32 的程式庫。

那麼,如果有一個程式庫將各個主要平台的程式庫萃取(abstract)出一個共通的程式庫,不就可以解決這個問題了。例如 Qt 正是這麼做,你的 C++ 程式如果只使用標準的 C++ 程式庫和 Qt 程式庫,你就可以把程式重新編譯之後在不同的平台(Linux,Unix,Windows)上執行。

語言 + 平台 + 程式庫
Java 就更了不起了,不但將程式庫統一起來,更將平台統一起來,也就是說程式不用重新編譯,就可以直接執行。但是也因此,多了一層 JVM,犧牲了一部分的效率。

跨語言的程式庫
Borland 的 VCL 程式庫是在 Windows 平台上相當受好評的一套程式庫,可以被 C++ 和 Object Pascal(Delphi)使用。其實「跨語言的程式庫」不是一種很好的說法,畢竟許多語言都可以連結外部原生程式庫,兩者不需要是同一種語言。但是這樣的連結是否需要大費周章,則有相當大的差異。而 Delphi 和 C++ Builder 使用 VCL 則是相當方便的。
即將在本月底問世的 Mac OS X,提供了 Cocoa 程式庫。Cocoa 程式庫可以被 Objective-C 和 Java 語言使用。Objective-C 和 Java 語言版的 Cocoa 程式庫相似性在九成以上。Java 在 Mac OS X 的原生程式設計上被簡化成一個純語言,完全不使用 Java 的 API,只使用 Cocoa 程式庫,這倒是挺特別的。(當然 Mac OS X 也另外會有 JVM 來支援一般的 J2SE)

語言規格 + 平台 + 程式庫 = 包山包海 ?
.NET 比 Java 的眼光更高,甚至準備將語言規格也統一起來。.NET 有一個 CLS(common language specification),任何語言只要符合 CLS 這個標準,就可以輕易地整合進 .NET 平台,享用 .NET 平台的資源。這一點就是 Java 比不上的。雖然別的語言一樣可以設計出編譯器來將程式編譯成 Java bytecode,在 JVM 上執行,但 Java 並沒有提供直接的支援,所以要移植一個語言到 Java,比移植一個語言到 .NET 來得困難。

.NET 雖然允許各種語言,但是為了因應 CLS,所以各個語言常常需要做出妥協更改語言本身,比方說 Visual Basic 的更改幅度就很大(Visual Basic 7 差不多是一個新的語言了),而 JScript 和 Visual C++ 的語言也都有改變。這種方式的語言中立性,無疑是削足適履。有了 CLS 的規範,這些語言會趨於一致,思維模式如出一轍,只有一些微不足道的小差異。歷史會證明,C# 會是 .NET 平台上獨大的語言,.NET 上的其它語言都將淪為點綴,這麼一來,跨語言的宣示,竟成了一個幌子。雖然我對 .NET 的語言中立性這點頗有疑異,但我倒是挺喜歡 .NET framework 的,我忍不住豎起大拇指稱讚 .NET framework 是「歹竹出好筍」。

.NET 的語言規格和程式庫都是統一的。命運多舛的 Eiffel 將 .NET 視為救命的浮木,準備將 Eiffel 移植到 .NET,但這麼一來,Eiffel 勢必得放棄自行開發的 Windows 專用程式庫 WEL(Windows Eiffel Library)與跨平台的程式庫(比方說 EiffelVision 等)。難道 Eiffel 沒有發現它所以為的浮木,其實是鱷魚偽裝的?

同樣的問題也會發生在 Delphi 上,如果 Delphi 準備移植到 .NET,也必須更改一部分的語言特性,並可能要放棄在 .NET 上使用 VCL(CLX)。Delphi 這麼做一點好處都沒有。

最亂的時代,最好的選擇
看完這篇文章,你可能已經頭昏腦脹了。沒關係,你只要記得下面這句話就好了:最亂的時代,最好的選擇 ...Java。

本文作者:蔡學鏞
張貼日期:3/05/01

| 首頁 | 聯絡我們 |
© 2009, O'Reilly Media, Inc. Taiwan Branch