• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>

            西城

            指尖代碼,手上年華

            聯(lián)系 聚合 管理
              20 Posts :: 0 Stories :: 62 Comments :: 0 Trackbacks
            這一陣在看CORBA,想找一個(gè)優(yōu)秀的開(kāi)源實(shí)現(xiàn)并不容易。MICO性能太差,沒(méi)有考慮,omniORB還好,只是配置著有點(diǎn)麻煩,
            Naming Service那部分用了好長(zhǎng)時(shí)間也沒(méi)讓程序成功運(yùn)行。orbit差不多是所有的實(shí)現(xiàn)里面最為高效的一個(gè),因?yàn)樗?/div>
            用C實(shí)現(xiàn)的,主要的綁定語(yǔ)言是C和perl。GNOME項(xiàng)目組正在用它。至少?gòu)膶?shí)用性角度看,它要比omniORB好的多。
            在看其中的例子時(shí),發(fā)現(xiàn)了在一些問(wèn)題的處理上,C的實(shí)現(xiàn)非常高效,而且并不復(fù)雜。相比之下,
            C++則顯得有點(diǎn)臃腫,效率低下。
            第一個(gè)問(wèn)題:類的實(shí)現(xiàn)。
            C語(yǔ)言里沒(méi)有類的概念,而IDL定義的接口則需要實(shí)現(xiàn)類似于對(duì)象的概念。C中的方法是將類作為方法的前綴,因?yàn)槲覀?/div>
            最終調(diào)用的還是方法,而將類作為函數(shù)名的前綴之后,就能保證方法名字的唯一,因?yàn)轭惷遣煌模粋€(gè)類中的函數(shù)
            名也是不同的。這樣就大大降低了開(kāi)銷,所有的一切都是通過(guò)函數(shù)調(diào)用來(lái)完成的。
            比如
            CORBA_ORB類中的resolve_initial_references方法,若參數(shù)是“RootPOA”
            則C中的實(shí)現(xiàn)是
            CORBA_ORB_resolve_initial_references(*orb,"RootPOA",ev);
            其中第一個(gè)參數(shù)就是調(diào)用此方法(resolve_initial_references)的類,第三個(gè)參數(shù)就是我所說(shuō)的第二個(gè)問(wèn)題:異常處理。
            C++中引入了throw...catch控制接口和exception類。優(yōu)點(diǎn)自不待言,缺點(diǎn)卻也不少,效率損失,程序結(jié)構(gòu)的混亂。
            在C的大部分函數(shù)中,我們可以看到另一種解決方法——額外的參數(shù)。
            通過(guò)附加一個(gè)額外的參數(shù)來(lái)表明錯(cuò)誤,然后檢測(cè)錯(cuò)誤,這樣的開(kāi)銷比用throw....catch小的多,而且沒(méi)有破壞程序
            結(jié)構(gòu)。
            C雖然只是一種面向過(guò)程的語(yǔ)言,沒(méi)有那么多的“高級(jí)特性”,但通過(guò)各種封裝,在不損失語(yǔ)言的簡(jiǎn)潔和高效的同時(shí),
            C的實(shí)現(xiàn)也是有很多優(yōu)點(diǎn)的。這也是為什么C總能穩(wěn)居語(yǔ)言排行榜的第二位的原因。
            posted on 2012-03-24 22:55 西城 閱讀(1786) 評(píng)論(26)  編輯 收藏 引用 所屬分類: C/C++

            Feedback

            # re: C和C++在兩個(gè)小問(wèn)題上的對(duì)比 2012-03-26 00:27 陳梓瀚(vczh)
            你雖然論證了C++編譯時(shí)間慢,但是這絲毫不影響運(yùn)行時(shí)效率啊。而且C++封裝層次高,所以你正確使用C++寫一個(gè)程序,花的時(shí)間要比C少很多,就算加上慢的編譯速度,也是更劃算的。

            舉個(gè)例子“這樣就大大降低了開(kāi)銷,所有的一切都是通過(guò)函數(shù)調(diào)用來(lái)完成的。
            ”。沒(méi)錯(cuò),這有開(kāi)銷,但這個(gè)開(kāi)銷是在編譯器里面的,最終生成的運(yùn)行時(shí)代碼,還是跟C語(yǔ)言一樣。一次性的東西都不用管它。  回復(fù)  更多評(píng)論
              

            # re: C和C++在兩個(gè)小問(wèn)題上的對(duì)比 2012-03-26 10:50 墨魂
            @陳梓瀚(vczh)
            但從orbit與omniORB的實(shí)現(xiàn)來(lái)說(shuō),我覺(jué)得還是C的實(shí)現(xiàn)更好,因?yàn)槟阌胦rbit寫分布式程序時(shí),最終服務(wù)器端的大部分代碼都直接有orbit幫你生成,你只用寫你需要實(shí)現(xiàn)的功能這一塊就好。但omniORB卻全是要自己手動(dòng)去寫。運(yùn)行時(shí)代碼是和C一樣,但throw...catch這樣的代碼一直都在程序中,不僅影響程序邏輯,在實(shí)現(xiàn)上也比直接傳一個(gè)參數(shù)低效的多  回復(fù)  更多評(píng)論
              

            # re: C和C++在兩個(gè)小問(wèn)題上的對(duì)比 2012-03-26 10:59 zjh
            @陳梓瀚(vczh)
            正確使用C++寫一個(gè)程序,花的時(shí)間要比C少很多
            正確使用c++比正確使用c,所花費(fèi)的時(shí)間是不可等日耳語(yǔ)的
            不敢茍同,c++太復(fù)雜了,稍不留神,就有可能出錯(cuò),效率低下,只要看看c++出版了那么多書籍就知道了,至今沒(méi)有一個(gè)編譯器能完全實(shí)現(xiàn)標(biāo)準(zhǔn)c++,也說(shuō)明c++過(guò)于復(fù)雜
              回復(fù)  更多評(píng)論
              

            # re: C和C++在兩個(gè)小問(wèn)題上的對(duì)比[未登錄](méi) 2012-03-26 15:27 陳梓瀚(vczh)
            你要是非要拿一個(gè)類庫(kù)來(lái)說(shuō),那我也可以說(shuō)我山寨過(guò)一個(gè)boost::spirit,那種優(yōu)美兼高效的parser寫法,C永遠(yuǎn)都做不到呢。這有什么意思。  回復(fù)  更多評(píng)論
              

            # re: C和C++在兩個(gè)小問(wèn)題上的對(duì)比[未登錄](méi) 2012-03-26 15:29 陳梓瀚(vczh)
            @zjh
            學(xué)習(xí)C++是一次性的,而寫C語(yǔ)言程序則是每一次都要做的事情。你這么比較不公平。一個(gè)更極端的例子,你花更多的時(shí)間去學(xué)習(xí)haskell,后面每一個(gè)程序的尺寸,可能是C語(yǔ)言的1/30,而且健壯性基本不用care因?yàn)檎Z(yǔ)言保證了你很難不健壯,性能也不差。這個(gè)開(kāi)發(fā)效率高不高,當(dāng)然是算總的時(shí)間,豈能算一個(gè)程序的時(shí)間?  回復(fù)  更多評(píng)論
              

            # re: C和C++在兩個(gè)小問(wèn)題上的對(duì)比 2012-03-26 15:37 墨魂
            @陳梓瀚(vczh)
            我是從一個(gè)類庫(kù)開(kāi)始說(shuō),但并不是只是這一個(gè)類庫(kù)這樣。比如QT和GTK相比,明顯QT的效率要比GTK相比要低的多。我比較的重點(diǎn)只是運(yùn)行的性能還有就是錯(cuò)誤處理那一塊的效率,至于你說(shuō)的那些優(yōu)美與高效的寫法,如果與同樣的C實(shí)現(xiàn)相比,也不一定就見(jiàn)得高效與優(yōu)美。
              回復(fù)  更多評(píng)論
              

            # re: C和C++在兩個(gè)小問(wèn)題上的對(duì)比[未登錄](méi) 2012-03-27 09:12 Chipset
            C語(yǔ)法和用法相對(duì)比較簡(jiǎn)單,C++語(yǔ)法和用法相對(duì)復(fù)雜,或者說(shuō)看你會(huì)不會(huì)用C++罷了。小程序比較快慢沒(méi)有意義,上下差不了幾個(gè)毫秒,可以看成誤差。我們還是比個(gè)比較大的程序吧,你覺(jué)得最新的Linux系統(tǒng)顯著比最新的Windows快嗎?前者是C寫的,后者是C++寫的。測(cè)試了很多項(xiàng),都是常用的,除了文件讀寫外(EXT4對(duì)NTFS,個(gè)人覺(jué)得是格式問(wèn)題),其它項(xiàng)Linux全軍覆沒(méi)。在Linux一個(gè)網(wǎng)站上比較的Ubantu和Win7,自己谷歌一下吧,我不解釋。  回復(fù)  更多評(píng)論
              

            # re: C和C++在兩個(gè)小問(wèn)題上的對(duì)比[未登錄](méi) 2012-03-27 09:43 Chipset
            http://www.phoronix.com/scan.php?page=home
            這里有很多比較,有硬件的,也有軟件的。
            至于你文中提到的C++拋出異常,我真想知道有多大開(kāi)銷,問(wèn)題是你拋什么異常,怎么拋異常,怎么處理異常。根據(jù)經(jīng)驗(yàn),異常處理會(huì)難倒很多C++老手,所以我懷疑你怎么使用異常,會(huì)不會(huì)很好的使用。
            C語(yǔ)言穩(wěn)居什么排行榜的事情跟效率有關(guān)嗎?既然C那么好用為何比排名第一呢?你不覺(jué)得你那種論斷荒唐嗎?
            至于你提到的圖形庫(kù),GTK+和QT,這玩意怎么比呀。作出的圖形不同的畫質(zhì)計(jì)算量會(huì)千差萬(wàn)別。都是用C寫的界面,GNOME和XFCE速度相差很大,這怎么解釋。即使如此,KDE也未必比Gnome慢哪里去,還在上面那個(gè)鏈接,你自己看。  回復(fù)  更多評(píng)論
              

            # re: C和C++在兩個(gè)小問(wèn)題上的對(duì)比 2012-03-27 11:53 zjh
            @Chipset
            誰(shuí)告訴你windows是用c++編寫的,windows內(nèi)核也是用c和匯編寫的  回復(fù)  更多評(píng)論
              

            # re: C和C++在兩個(gè)小問(wèn)題上的對(duì)比[未登錄](méi) 2012-03-27 12:43 Chipset
            唉,我說(shuō)樓上的那位。Win內(nèi)核是用C++寫的,少量Intel匯編,你去問(wèn)微軟的架構(gòu)師好了,我不解釋。。。  回復(fù)  更多評(píng)論
              

            # re: C和C++在兩個(gè)小問(wèn)題上的對(duì)比 2012-03-27 12:53 墨魂
            @Chipset
            ubuntu并不能代表LINUX,它只是一個(gè)類似WINDOWS的傻瓜化的操作系統(tǒng)。
            WINDOWS和INTEL的聯(lián)盟使得WINDOWS針對(duì)x86平臺(tái)進(jìn)行優(yōu)化,但LINUX沒(méi)有這樣的支持,而且linux要支持各種硬件平臺(tái),所以代碼要盡量通用,可移植,當(dāng)然在某些方面比不過(guò)只做x86的windows.  回復(fù)  更多評(píng)論
              

            # re: C和C++在兩個(gè)小問(wèn)題上的對(duì)比[未登錄](méi) 2012-03-27 12:54 Chipset
            @zjh
            順便給你掃盲一下吧。微軟的所有產(chǎn)品(除了.net框架的一部分基類用了C#),其余是一色的C++程序,就連C#編譯器都不例外,當(dāng)然了,個(gè)別地方有點(diǎn)Intel匯編。
            若干年前Windows Phone上嘗試了一下用C#寫了個(gè)軟鍵盤程序,發(fā)現(xiàn)速度太慢,最終只好又退回到C++。DOS是用匯編寫的,從Win95以后,都是C++代碼外加少量匯編。Win2K的代碼泄漏過(guò)一次,不知道現(xiàn)在網(wǎng)上是否還能下載到,是用C++寫的,這個(gè)能看到。

            不要覺(jué)得WinAPI是些C代碼就認(rèn)為Win內(nèi)核是用C寫的,你可以去問(wèn)微軟的架構(gòu)師。。。  回復(fù)  更多評(píng)論
              

            # re: C和C++在兩個(gè)小問(wèn)題上的對(duì)比 2012-03-27 12:59 墨魂
            @Chipset
            KDE的內(nèi)存占用要比Gnome大很多,這是我自己測(cè)得的結(jié)果。如果KDE真如你說(shuō)的那么好,各大發(fā)行版為什么都默認(rèn)的是GNOME而不是KDE,連SUSE在12.1都是。C不是第一,只是因?yàn)橄鄬?duì)于JAVA來(lái)說(shuō),C還是太難。愿意學(xué)下去的太少。不過(guò)3月分的語(yǔ)言排行榜你應(yīng)該看過(guò),JAVA--17.110%,比上月下滑2.60%,C占
            17.087%,上漲1.82%,這總不會(huì)是無(wú)緣無(wú)故的。C++8.074%,下滑0.71%,并不說(shuō)C++不好,只是有太多自以為是的C++程序員了。  回復(fù)  更多評(píng)論
              

            # re: C和C++在兩個(gè)小問(wèn)題上的對(duì)比[未登錄](méi) 2012-03-27 13:31 Chipset
            @墨魂
            唉,那個(gè)排名能說(shuō)明個(gè)啥呀,跟效率沒(méi)關(guān)系是不是?
            其實(shí)C++和C速度上沒(méi)差別,你可以看下struct和class的內(nèi)存布局,內(nèi)存布局都一樣,哪來(lái)的速度差別呀。。。
            C++唯一慢的地方是虛函數(shù)(C沒(méi)有),需要查虛表,就一兩條指令的開(kāi)銷帶來(lái)的好處是不言而喻的。。。
            至于Gnome和KDE,畫面質(zhì)量不同,內(nèi)存和計(jì)算量相差那么大,比速度和內(nèi)存有意思嗎?你咋不拿控制臺(tái)給Metro比速度和內(nèi)存呀。。。
            C++是有很多缺點(diǎn)被很多人指責(zé),編譯慢,語(yǔ)法太復(fù)雜,新手很容易寫出爛代碼。。。這都是真的,但是不恰恰說(shuō)明很多人在用C++嗎?否則怎么可能發(fā)現(xiàn)這么多問(wèn)題呢。。。就如同我們天天罵windows一樣,你見(jiàn)過(guò)幾個(gè)人罵Linux?沒(méi)有幾個(gè)人用,哪里能發(fā)現(xiàn)那么多問(wèn)題。。。  回復(fù)  更多評(píng)論
              

            # re: C和C++在兩個(gè)小問(wèn)題上的對(duì)比[未登錄](méi) 2012-03-27 13:35 Chipset
            @墨魂
            如果你還要比,我還能給你舉出更多例子說(shuō)明C++比C快,耗費(fèi)內(nèi)存也少,如果有人說(shuō)C++比C快耗費(fèi)內(nèi)存少,我同樣也能舉出很多反面的例子。。。  回復(fù)  更多評(píng)論
              

            # re: C和C++在兩個(gè)小問(wèn)題上的對(duì)比 2012-03-27 15:13 zjh
            @Chipset
            你是不是想說(shuō)微軟的C編譯器和鏈接器也是c++寫的?,操作系統(tǒng)內(nèi)核從來(lái)也沒(méi)有用c++寫過(guò),注意是內(nèi)核,不是操作系統(tǒng),windows是微內(nèi)核。
            不巧,我還真有win2k的源代碼,要不要貼上來(lái)讓你看看? 先給自己掃盲吧  回復(fù)  更多評(píng)論
              

            # re: C和C++在兩個(gè)小問(wèn)題上的對(duì)比[未登錄](méi) 2012-03-27 16:13 Chipset
            @zjh
            建議你谷歌一下吧,或問(wèn)微軟的架構(gòu)師,感覺(jué)這玩意沒(méi)啥好爭(zhēng)論的。  回復(fù)  更多評(píng)論
              

            # re: C和C++在兩個(gè)小問(wèn)題上的對(duì)比[未登錄](méi) 2012-03-27 16:31 Chipset
            就說(shuō)NT吧,不是微(micro)內(nèi)核,也不是單(monolithic)內(nèi)核,應(yīng)該算Hybrid。你可以搜索到NT架構(gòu),我也不清楚你說(shuō)哪一部分。HAL層我估計(jì)應(yīng)該用匯編,據(jù)說(shuō)這些匯編主要來(lái)自一個(gè)祖籍臺(tái)灣人的貢獻(xiàn)(你可以了解一下微軟的歷史,那幾個(gè)技術(shù)鼻祖)。再上面一層(Kernel mode drivers 和 micro kernel),古老的代碼應(yīng)該是C寫的,后來(lái)改寫的代碼是C++的,再上面也是這樣,古老的代碼是C的,后來(lái)的是C++的。其實(shí)不僅Windows,Office也是這樣的,最古老的代碼是匯編,后來(lái)的用C,C++出現(xiàn)以后所有的新東西都用C++來(lái)寫。你不是有win2k代碼嗎,你最好找到我說(shuō)的那一層看看是不是這樣。  回復(fù)  更多評(píng)論
              

            # re: C和C++在兩個(gè)小問(wèn)題上的對(duì)比 2012-03-27 16:48 Chipset
            @zjh
            這里有個(gè)簡(jiǎn)要的圖和介紹,我不明白你指代那一部分:
            http://en.wikipedia.org/wiki/Architecture_of_Windows_NT

            用C++寫操作系統(tǒng)內(nèi)核不是新聞,用Java寫的都有。。。

            這里有用什么語(yǔ)言編寫的介紹:
            http://www.lextrait.com/vincent/implementations.html
            這里也可以查到:
            http://www2.research.att.com/~bs/applications.html
              回復(fù)  更多評(píng)論
              

            # re: C和C++在兩個(gè)小問(wèn)題上的對(duì)比 2012-03-27 17:48 墨魂
            @Chipset
            GNOME和KDE的差別有多大,你如果真的拿命令行和win8的那個(gè)什么界面比。我也沒(méi)什么可說(shuō)的。GNOME3.2和KDE4.7是差不多同時(shí)的產(chǎn)品,你自己可以去看他們之間究竟是不是有你所說(shuō)的那么大的差別。

            你之前說(shuō)排名沒(méi)用,現(xiàn)在又來(lái)說(shuō)C++有那么多人用,那這又有什么用?我覺(jué)得排名里C++不斷下滑是有原因的,你若覺(jué)得沒(méi)什么問(wèn)題也罷。  回復(fù)  更多評(píng)論
              

            # re: C和C++在兩個(gè)小問(wèn)題上的對(duì)比 2012-03-27 19:19 zjh
            @Chipset
            你說(shuō)什么就是什么吧,反正我手里的win2k源代碼不是c++的,難道是盜版?
            java寫操作系統(tǒng),是畢業(yè)設(shè)計(jì)么? 也許等到芯片的計(jì)算能力大大提高后,可以吧java虛擬機(jī)固化到芯片,就可以用java寫操作系統(tǒng)
            摘錄一段代碼
            VOID
            KiInitSystem (
            VOID
            )

            /*++

            Routine Description:

            This function initializes architecture independent kernel structures.

            Arguments:

            None.

            Return Value:

            None.

            --*/

            {

            ULONG Index;

            //
            // Initialize dispatcher ready queue listheads.
            //

            for (Index = 0; Index < MAXIMUM_PRIORITY; Index += 1) {
            InitializeListHead(&KiDispatcherReadyListHead[Index]);
            }

            //
            // Initialize bug check callback listhead and spinlock.
            //

            InitializeListHead(&KeBugCheckCallbackListHead);
            KeInitializeSpinLock(&KeBugCheckCallbackLock);

            //
            // Initialize the timer expiration DPC object.
            //

            KeInitializeDpc(&KiTimerExpireDpc,
            (PKDEFERRED_ROUTINE)KiTimerExpiration, NIL);

            //
            // Initialize the profile listhead and profile locks
            //

            KeInitializeSpinLock(&KiProfileLock);
            InitializeListHead(&KiProfileListHead);

            //
            // Initialize the active profile source listhead.
            //

            InitializeListHead(&KiProfileSourceListHead);

            //
            // Initialize the timer table, the timer completion listhead, and the
            // timer completion DPC.
            //

            for (Index = 0; Index < TIMER_TABLE_SIZE; Index += 1) {
            InitializeListHead(&KiTimerTableListHead[Index]);
            }

            //
            // Initialize the swap event, the process inswap listhead, the
            // process outswap listhead, the kernel stack inswap listhead,
            // the wait in listhead, and the wait out listhead.
            //

            KeInitializeEvent(&KiSwapEvent,
            SynchronizationEvent,
            FALSE);

            InitializeListHead(&KiProcessInSwapListHead);
            InitializeListHead(&KiProcessOutSwapListHead);
            InitializeListHead(&KiStackInSwapListHead);
            InitializeListHead(&KiWaitInListHead);
            InitializeListHead(&KiWaitOutListHead);

            //
            // Initialize the system service descriptor table.
            //

            KeServiceDescriptorTable[0].Base = &KiServiceTable[0];
            KeServiceDescriptorTable[0].Count = NULL;
            KeServiceDescriptorTable[0].Limit = KiServiceLimit;
            #if defined(_IA64_)

            //
            // The global pointer associated with the table base is
            // placed just before the service table.
            //

            KeServiceDescriptorTable[0].TableBaseGpOffset =
            (LONG)(*(KiServiceTable-1) - (ULONG_PTR)KiServiceTable);
            #endif
            KeServiceDescriptorTable[0].Number = &KiArgumentTable[0];
            for (Index = 1; Index < NUMBER_SERVICE_TABLES; Index += 1) {
            KeServiceDescriptorTable[Index].Limit = 0;
            }

            //
            // Copy the system service descriptor table to the shadow table
            // which is used to record the Win32 system services.
            //

            RtlCopyMemory(KeServiceDescriptorTableShadow,
            KeServiceDescriptorTable,
            sizeof(KeServiceDescriptorTable));

            //
            // Initialize call performance data structures.
            //

            #if defined(_COLLECT_FLUSH_SINGLE_CALLDATA_)

            ExInitializeCallData(&KiFlushSingleCallData);

            #endif

            #if defined(_COLLECT_SET_EVENT_CALLDATA_)

            ExInitializeCallData(&KiSetEventCallData);

            #endif

            #if defined(_COLLECT_WAIT_SINGLE_CALLDATA_)

            ExInitializeCallData(&KiWaitSingleCallData);

            #endif

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

            # re: C和C++在兩個(gè)小問(wèn)題上的對(duì)比[未登錄](méi) 2012-03-28 09:20 Chipset
            @zjh
            Java寫系統(tǒng)還真有,也不是什么畢業(yè)設(shè)計(jì)。你可以谷歌下JNode,除了一點(diǎn)匯編,其它全是用Java寫的。
            至于你說(shuō)把虛擬機(jī)固化到芯片里,雖然我沒(méi)見(jiàn)哪家這么干,但是我確實(shí)聽(tīng)說(shuō)有的ARM芯片可以直接執(zhí)行字節(jié)碼。

            我們做嵌入式,芯片的計(jì)算能力非常有限,內(nèi)存也跟臺(tái)式機(jī)沒(méi)得比,是很在乎資源消耗的。以前一直認(rèn)為C++比C慢很多,耗費(fèi)資源也多,關(guān)于C和C++之間的速度差別查閱了很多資料,評(píng)測(cè)過(guò)N次,發(fā)現(xiàn)幾乎沒(méi)啥差別。

            C++的缺點(diǎn)是很明顯的,新手很容易寫出垃圾代碼,速度慢耗費(fèi)內(nèi)存多,但優(yōu)點(diǎn)也很明顯。我們目前做的一個(gè)程序大約2百萬(wàn)行源代碼,C++代碼大約90%以上,C代碼大約5%,還有1%不到的Lua。如果C++的部分也用C來(lái)做,你想想源代碼量會(huì)有多大,維護(hù)起來(lái)會(huì)有多痛苦...  回復(fù)  更多評(píng)論
              

            # re: C和C++在兩個(gè)小問(wèn)題上的對(duì)比[未登錄](méi) 2012-03-28 09:33 Chipset
            @墨魂
            Gnome和Xfce都用C,但是速度差別那么大怎么解釋?很多事情跟語(yǔ)言關(guān)系不大對(duì)不對(duì)。再舉個(gè)例子,Chrome,F(xiàn)ireFox,IE都用C++來(lái)寫,速度和資源消耗是不是也差別很大?這又怎么解釋?
            我再舉個(gè)例子吧,MTL聽(tīng)說(shuō)過(guò)吧,做計(jì)算的。做數(shù)值計(jì)算,C和C++沒(méi)法跟Fortran比速度,同樣的算法,速度得差20%,但是MTL開(kāi)發(fā)出來(lái)后,尤其4.0以后把Fortran都秒飛了,你能說(shuō)C++不行?那為啥不用C來(lái)做,如果C真的那么快?

            任何語(yǔ)言都有優(yōu)點(diǎn)和缺點(diǎn),否則某種語(yǔ)言早就一統(tǒng)江湖了。。。  回復(fù)  更多評(píng)論
              

            # re: C和C++在兩個(gè)小問(wèn)題上的對(duì)比 2012-03-28 11:17 墨魂
            @Chipset
            我沒(méi)有說(shuō)過(guò)C就一定比C++好,問(wèn)題都是在庫(kù)的設(shè)計(jì)上,C++的庫(kù)設(shè)計(jì)的不好會(huì)有性能損耗,設(shè)計(jì)的好的話跟C比也會(huì)很多優(yōu)勢(shì)。

            MTL是很好,但沒(méi)有用C來(lái)做 就不是說(shuō)用C不行。只是剛好這個(gè)庫(kù)用C++來(lái)寫了而已。  回復(fù)  更多評(píng)論
              

            # re: C和C++在兩個(gè)小問(wèn)題上的對(duì)比[未登錄](méi) 2012-03-28 16:04 Chipset
            @墨魂
            Gnome和KDE都是應(yīng)用,Linus Torvalds也在公開(kāi)場(chǎng)合說(shuō)過(guò)KDE做的很不錯(cuò),否則在那個(gè)C的世界KDE早死了。

            Qt的版本升級(jí)很快,看來(lái)很多人在用(如果沒(méi)幾個(gè)人用那還有必要頻繁升級(jí)嗎?)再想想Qt商業(yè)應(yīng)用得花錢買版權(quán),如果Qt跟GTK+比真的那么差,誰(shuí)愿意花錢買不好的東西呢?用免費(fèi)的GTK+(C)或gtkmm(給C++用)豈不更好?

            順便說(shuō)下zjh貼的那段代碼,我真看不出是C的。C89和C94沒(méi)有//的注釋符號(hào),C99的規(guī)定是何年月啦,微軟的編譯器哪里能升級(jí)那么快?Win2K能趕得上嗎?  回復(fù)  更多評(píng)論
              

            # re: C和C++在兩個(gè)小問(wèn)題上的對(duì)比 2012-03-28 16:33 墨魂
            @Chipset
            QT主要是功能較為豐富,而GTK+主要是做界面。再者KDE出來(lái)的比較早,GNOME只是不滿于KDE的設(shè)計(jì)而成立的。所以單論界面來(lái)說(shuō),GNOME并不比KDE差,再者KDE設(shè)計(jì)的太過(guò)復(fù)雜,并不符合一般用戶的使用習(xí)慣,所以GNOME會(huì)后來(lái)居上。  回復(fù)  更多評(píng)論
              

            久久综合狠狠色综合伊人| 99久久精品费精品国产 | 久久99亚洲网美利坚合众国| 久久夜色精品国产噜噜麻豆| 国内精品久久久久| 国产无套内射久久久国产| 亚洲国产成人精品女人久久久 | 久久国产精品视频| 久久久国产亚洲精品| 久久久无码一区二区三区| 国产成人久久精品二区三区| 久久久久久曰本AV免费免费| 99久久99久久精品国产片果冻 | 91精品国产色综合久久| 成人久久综合网| 一本久久a久久精品vr综合| 国产精品久久波多野结衣| 久久久久久噜噜精品免费直播| 久久AV无码精品人妻糸列| 久久99国产亚洲高清观看首页| 精品久久久久久久久免费影院 | 久久精品亚洲日本波多野结衣| 久久久精品免费国产四虎| 精品国产乱码久久久久软件| 激情五月综合综合久久69| 久久精品国产亚洲AV麻豆网站 | 久久久精品国产sm调教网站 | 亚洲精品国产综合久久一线| 精品国产福利久久久| 亚洲国产精品高清久久久| 久久精品国产男包| 国产精品伦理久久久久久| 99久久国产热无码精品免费| 精品熟女少妇AV免费久久| 精品国产乱码久久久久软件| 中文字幕久久精品| 亚洲国产精品成人AV无码久久综合影院| 久久久久久夜精品精品免费啦| 国内高清久久久久久| 久久精品国产久精国产果冻传媒| 久久乐国产精品亚洲综合|