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

跨平臺(tái)的基礎(chǔ)是虛擬機(jī)，就我所知，VC.NET好象是可以同時(shí)對(duì)原生和基于虛擬的兩個(gè)環(huán)境做開發(fā)的。
  回復(fù)  更多評(píng)論
  

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

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

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

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

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

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


  回復(fù)  更多評(píng)論
  

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

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

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

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

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

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

愛之深，痛之切，適當(dāng)抱怨一下也未嘗不可。。。  回復(fù)  更多評(píng)論
  

編譯跨平臺(tái)，標(biāo)準(zhǔn)c/c++，在vc下開發(fā)嵌入式應(yīng)用，很普遍的事情  回復(fù)  更多評(píng)論
  

你說的很有道理，“生成的目標(biāo)文件完全一致”，這在C＋＋的討論里，稱為“有共同的二進(jìn)制格式”，但事實(shí)上有兩個(gè)問題：

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

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

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

這些事情就是虛擬機(jī)做的。C＋＋不考慮虛擬機(jī)，所以也就不可能有運(yùn)行時(shí)機(jī)制上的跨平臺(tái)。但是C＋＋的語法當(dāng)然是跨平臺(tái)的。還有就是庫可以跨平臺(tái)。比如網(wǎng)絡(luò)，一個(gè)ACE庫，確實(shí)跨了很多平臺(tái)。


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