"大家都知道現(xiàn)在C/C++的編譯是分為兩個部分的,即編譯和連接:源文件經(jīng)編譯后生成目標文件,然后再連接為可執(zhí)行文件."——現(xiàn)在？你的意思是以前不是了？原生開發(fā)環(huán)境下誕生的程序都上兩個階段吧，一個就是編譯成目標文件，然后Linker把這些目標文件以及一些資源文件連接成最后的符合PE/COFF標準的EXE文件或者COM等可執(zhí)行文件。

跨平臺的基礎是虛擬機，就我所知，VC.NET好象是可以同時對原生和基于虛擬的兩個環(huán)境做開發(fā)的。
  回復  更多評論
  

跨平臺的一個方式是虛擬機，另一個方式是提供一致的API和ABI，也就是要求所有操作系統(tǒng)支持相同的可執(zhí)行文件格式，完整支持POSIX，這個似乎很難達到。

所以目前看來，虛擬機是唯一的辦法。

從C＋＋語言的發(fā)展方向上，很難看到他們有在語言層面上跨平臺的打算。

退而求其次，或許能夠依賴于某個工具，幫助檢查源代碼的可移植性。  回復  更多評論
  

@FrameSniper
"現(xiàn)在？你的意思是以前不是了？"
----------
當然不是了,我的文字不好,沒有講明白,謝謝你指正.

另外,我不認為跨平臺只有依靠虛擬機.像cpunion所說,只要系統(tǒng)提供一致的接口就行.但是,如果接口差異不是很大,我想應該可以靠編譯器的工作來轉(zhuǎn)換.
我的意思也不是要讓生成的可執(zhí)行文件實現(xiàn)跨平臺,而是在一個中間代碼的層次實現(xiàn),而后由編譯器針對各系統(tǒng)的不同而生成不同的程序.雖然這也不是完全的跨平臺,但在開發(fā)者的角度看也差不多了,而且可以通過編譯器的實現(xiàn)來將中間代碼的編譯速度提高,這樣也可以實現(xiàn).NET所謂的即時編譯,即第一次運行的時候編譯,以后就不用編譯了.其實在虛擬機上,也不是可以生成目標操作系統(tǒng)的機器代碼嗎,但它的效率應該不及C/C++了吧.


  回復  更多評論
  

@cpunion
從C＋＋語言的發(fā)展方向上，很難看到他們有在語言層面上跨平臺的打算。
--------------
確實,但我覺得現(xiàn)在語言層面動態(tài)的需求是很大的,尤其是做應用開發(fā)的.而C++卻是在已經(jīng)做得不錯的效率上下工夫,而且現(xiàn)在又要加入一些保證安全的語言特征.這可不符合大勢所趨啊.所以我覺得C++也會往這方面發(fā)展的吧.
其實我覺得那些C++的元老對C++的發(fā)展起了太大的作用,而他們又是比較保守的,所以導致C++發(fā)展緩慢.我覺得現(xiàn)在JAVA的方式不錯,通過JCP社區(qū)最終決定它的發(fā)展方向.
也許也是我錯了吧:也許C++并不想走"大眾化"的道路,或是那些元老不想讓它走.
但我認為使用者才是擁有最終決定權(quán)的.  回復  更多評論
  

C/C++代碼有很多方面在跨平臺時有問題，并不是JIT編譯器可以解決的，主要是畎；它太底層了。

JIT本身也是虛擬機的一部分，采用它就得確定使用虛擬機。

C＋＋跨平臺的問題，通過良好的設計和編寫規(guī)范代碼，是可以實現(xiàn)的，很多產(chǎn)品都是跨平臺的了。

C＋＋最大的問題應該是動態(tài)性問題，C＋＋除了虛函數(shù)和簡單的RTTI以外，基本上沒有任何動態(tài)性，而動態(tài)性卻是分布式編程中基本的需求。目前C＋＋編寫分布式組件，都需要先以一種IDL來編寫接口，再生成一堆調(diào)用代碼，而很多其它語言則可以在語言內(nèi)解決這個問題。

c++0x正在加入一個XTI（擴展類型信息），不過還沒有看到實現(xiàn)產(chǎn)品，所以也無法評論。我希望它不要像上一個標準中的RTTI這么簡單，而是要以一種語言層面的東西加入進來。
比如我在類聲明時寫成dynamic class X;則這個類在編譯后，將在全局類型表中注冊自己，并可以通過全局名稱查找到類，還可以由類查找所有成員的名稱、類型等，也就是反射，當然希望還能走得更遠些，比如動態(tài)創(chuàng)建、動態(tài)加載類型庫等。

愛之深，痛之切，適當抱怨一下也未嘗不可。。。  回復  更多評論
  

編譯跨平臺，標準c/c++，在vc下開發(fā)嵌入式應用，很普遍的事情  回復  更多評論
  

你說的很有道理，“生成的目標文件完全一致”，這在C＋＋的討論里，稱為“有共同的二進制格式”，但事實上有兩個問題：

第一： “二進制格式” 的標準，不在語言里，而在操作系統(tǒng)手上，可惜操作系統(tǒng)之間往往是沒有這個共同標準。所以只能通過編譯成一個“偽代碼”，再去調(diào)操作系統(tǒng)對應的功能。

第二，有了偽代碼，在去調(diào)系統(tǒng)對應功能時，仍然可能遇上問題。那就是各個操作系統(tǒng)對應功能的實現(xiàn)差別太大，這時簡單地“調(diào)用”就不可能了。比如有功能A，在操作系統(tǒng)O1上，只需要一個函數(shù)，而在操作系統(tǒng)O2上，需要3個函數(shù)的組合才能實現(xiàn)。所以這個“調(diào)用”，就得“智能”一點，這樣就成了“虛擬機”了，也就是在不同操作系統(tǒng)，有不同的虛擬機實現(xiàn)對外統(tǒng)一的接口。舉一個典型例子，你想吃漢堡，這時有三種情況：

1.本地有麥當勞，去麥當勞買一個，因為麥當勞的漢堡比較地道。
2.本地沒有麥當勞，但有肯德基，去肯德基買一個。
3.本地根本沒有賣漢堡的店。。。沒關(guān)系，親處去找面粉，雞肉什么的，做一個，只要你愿意等。

這些事情就是虛擬機做的。C＋＋不考慮虛擬機，所以也就不可能有運行時機制上的跨平臺。但是C＋＋的語法當然是跨平臺的。還有就是庫可以跨平臺。比如網(wǎng)絡，一個ACE庫，確實跨了很多平臺。


比如你想買一份 麥當勞的堡，但你現(xiàn)在所在的城市居然沒有麥當勞，那就不好辦了。。。  回復  更多評論