• <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>

            huaxiazhihuo

             

            C++雜談

                   C++是我最喜歡的語言,它集自由、博大、復(fù)雜、簡約、高效于一身,又能很好地均衡這些特點(diǎn),使它們和平共處,將“不為用到的任何特性付出一點(diǎn)點(diǎn)代價(jià)”的宗旨貫徹到底,其他的任何一種語言的都不具備像C++這樣的內(nèi)涵,使用C++之時(shí),直有C++在手,江山我有的感覺。C雖然能讓你掌管一切,但用C開發(fā),有如戴著鐐銬在跳舞,無時(shí)不刻要小心翼翼地人肉管理一切細(xì)節(jié),實(shí)在太累了。而用C#、JAVA等其他語言時(shí),雖然養(yǎng)尊處優(yōu),但想走不尋常路之時(shí),又處處受限制,很有點(diǎn)寄人籬下的味道,未免不痛快。只有C++,既能下,又能上,進(jìn)可攻,退可守,想怎么樣就怎么樣,盡情地飛翔。只要你愿意,你就可以在這一片世界里隨心所欲地發(fā)揮你的一切聰明才智,創(chuàng)造出種種奇技淫巧,而不會受到一點(diǎn)點(diǎn)約束。問題來了,自由得過頭了,就失去了控制,自由未必是好事。好多人,自由得甚至忘記了他要用C++的根本目的是什么,于是,C++到了他的手里,就變成為自由而自由,為復(fù)雜而復(fù)雜的利器,不但用它來折磨自己,還用它來迷惑別人,以致于忽視了原本要解決的問題,這樣一來,問題就很嚴(yán)重了。好的工具本來就是要用來做點(diǎn)實(shí)事的,做不了實(shí)事,要拿什么來證明自己呢?

                    對于C++,沒什么好說的。但C++的教育,就有太多的不滿,要指責(zé)之處,也實(shí)在太多了,其中最為人詬病,就是很多C++的教材,都鼓勵(lì)讀者將注意力集中到C++的細(xì)節(jié)中,而忘記了如何用C++來簡潔質(zhì)樸地來表達(dá)設(shè)計(jì)思路。關(guān)于這一點(diǎn),很多達(dá)人君子也已經(jīng)一再嚴(yán)厲地批評再批評。我也不想重復(fù)他們的論調(diào),只想舉兩個(gè)例子。

                    C++因缺乏GC,而廣受非議。但內(nèi)存管理,其實(shí)不值得議論再議論,只要設(shè)計(jì)編寫得當(dāng),少耍小聰明,代碼中出現(xiàn)new和delete的次數(shù)可以很少很少,就算出現(xiàn),也只會出現(xiàn)于底層代碼中。為了彌補(bǔ)GC的缺席,C++界中發(fā)明了種種內(nèi)存管理的巧妙手法,其中最得力的一種辦法就是智能指針,而出現(xiàn)于標(biāo)準(zhǔn)庫中就是大名鼎鼎的auto_ptr了,甚至有人說,一本C++的教材,只要不介紹auto_ptr,就不屬于合格的教科書。但其實(shí),auto_ptr并不見得那么重要,好比以下的代碼
            Int* pa = new int;
            ……
            delete pa;
                    這代碼確實(shí)不好,于是該auto_ptr上場表演,變成
            auto_ptr<int*> pa(new int);
                    delete消失了,何其美妙,但其實(shí),最樸實(shí)的代碼,連new都可以不用的,既然沒有new,就不需要auto_ptr了,最簡潔的代碼,非常簡單。
            Int a = 0;
                    一行就好,什么都用不了,很多出現(xiàn)auto_ptr的地方,直接用局部變量就可以了。不能使用局部變量的地方,就屬復(fù)雜的內(nèi)存管理了,在那里分配,在那里釋放,都很有必要細(xì)細(xì)地斟酌一番,auto_ptr并非什么萬能丹,一有內(nèi)存分配,就搬出auto_ptr,只怕屬本本主義的作風(fēng)。即此以觀,什么share_ptr,scope_ptr,也就那么一點(diǎn)點(diǎn)作用而已,無須大書特書。

                    我承認(rèn),BOOST精妙無比,那都是C++程序聰明才智的結(jié)晶,但其實(shí),真正搬得上臺面,發(fā)揮大作用的玩意,為數(shù)并不多,好比Tuple,可以方便地返回函數(shù)中的多個(gè)結(jié)果,例如……(請大家自己動(dòng)手,或baidu或google),乍聽起來,似乎美妙無比。但其實(shí),沒什么作用,什么時(shí)候,我們需要從函數(shù)中返回多個(gè)值?需要從函數(shù)中返回多值時(shí),我會盡量地寫本地代碼,實(shí)在必須調(diào)用函數(shù)了,只好搬出指針或引用,將參數(shù)傳遞進(jìn)去,如果數(shù)量太多了,那就動(dòng)用結(jié)構(gòu),用結(jié)構(gòu)組織這些返回值,這一切,做起來,并沒什么太大的不便。但是如果動(dòng)用Tuple返回多個(gè)結(jié)果,可能方便了那么一點(diǎn)點(diǎn),卻將導(dǎo)致代碼難以維護(hù),因?yàn)門uple里面的值各表示了什么意思,無法直接從代碼中看得出來,用過Tuple的同學(xué)自然知道我要說什么。Tuple的實(shí)現(xiàn)非常巧妙,如此費(fèi)盡心思弄出來的東西,不過是一只漂亮花瓶而已,真讓人扼腕嘆息不已,很多C++的庫,尤其是BOOST,都是這個(gè)樣子,看起來很精致,用起來,卻完全不是那么一回事,而且還引入很多不必要復(fù)雜性,世人稱心智包袱。

                    ……
                    用C++做設(shè)計(jì),很容易就導(dǎo)致庫設(shè)計(jì),如果設(shè)計(jì)出來的庫有用好用,那也罷了,問題是費(fèi)了九牛二虎之力,搞出來的東西,半點(diǎn)得不到別人的認(rèn)可,甚至連自己都無法認(rèn)可,那就太不應(yīng)該了。
                    用C++寫代碼,老老實(shí)實(shí)地寫代碼,不要忘記了編程的用意,別沉浸于語言中,盡量將代碼寫得直白易懂,少賣弄聰明才智, 慎用C++的一切特性,繼承、虛函數(shù)、操作符重載、模板、異常、new delete、……,更加不要用它們創(chuàng)造出什么奇技淫巧,必須用它們的時(shí)候,必須要有使用它們的理由。確實(shí)存在必須使用它們的理由,還堅(jiān)決不用,那就是傻瓜和偏執(zhí)狂了,這不是合格的C++碼農(nóng),C++雖然不喜歡胡作非為的搗蛋鬼,但也杜絕一切墨守成規(guī)的書呆子。

            posted on 2011-07-11 09:29 華夏之火 閱讀(2801) 評論(30)  編輯 收藏 引用

            評論

            # re: C++雜談 2011-07-11 10:14 Enic

            90%贊同,感同身受,,,  回復(fù)  更多評論   

            # re: C++雜談 2011-07-11 10:22 Skill

            那是因?yàn)槟悴欢檬褂肂oost,標(biāo)準(zhǔn)委員會幾千人的結(jié)晶就被你一句話否決了
            好好學(xué)一學(xué)吧 你太依賴auto_ptr了  回復(fù)  更多評論   

            # re: C++雜談 2011-07-11 10:52 華夏之火

            @Skill
            只怕閣下更不懂得Boost和auto_ptr,而且也未必明白在下的文章要說什么,只想說在下最不依賴auto_ptr了
              回復(fù)  更多評論   

            # re: C++雜談 2011-07-11 11:39 溪流

            說得挺中肯的,頂一下!  回復(fù)  更多評論   

            # re: C++雜談 2011-07-11 11:51 fx

            代碼還是實(shí)用點(diǎn),簡單點(diǎn)的好。  回復(fù)  更多評論   

            # re: C++雜談 2011-07-11 11:56 fx

            智能指針上有點(diǎn)略微不贊同,一個(gè)大型軟件項(xiàng)目,參與者眾多,水平參差不齊。不用智能指針的話,太容易有內(nèi)存泄漏了。教科書的受眾,更多的是水平普通的開發(fā)人員,而不是小部分的C++精英。  回復(fù)  更多評論   

            # re: C++雜談 2011-07-11 12:00 華夏之火

            大多數(shù)的內(nèi)存泄漏,都是設(shè)計(jì)上的缺陷@fx
              回復(fù)  更多評論   

            # re: C++雜談[未登錄] 2011-07-11 21:08 kevin

            這篇文章只是暴露出了你的弱點(diǎn)。因?yàn)椴荒苷莆誄的細(xì)節(jié)而畏懼,對BOOST不了解而對其嗤之以鼻。C++因?yàn)橄忍烊毕萜渥畲蟮恼系K是如何對問題解偶,BOOST在這方面是典范,不僅提供了一系列的解偶工具,其本身也是一個(gè)很好的范例。多花點(diǎn)時(shí)間磨練一下自己吧。  回復(fù)  更多評論   

            # re: C++雜談[未登錄] 2011-07-11 21:38 楊粼波

            一切遵循木桶效應(yīng),如果項(xiàng)目中有一兩個(gè)水平低的,那么整個(gè)項(xiàng)目的質(zhì)量都可能會被這一兩個(gè)人所拖累。

            如果一個(gè)人,掌握不了復(fù)雜的東西。風(fēng)險(xiǎn)最小原則,那么就不要使用復(fù)雜的東西,那將會把一切都搞砸掉。

            不論是什么語言,什么技術(shù),在技藝好的人手里,都能玩轉(zhuǎn)自如,而在一個(gè)初學(xué)者,一個(gè)愚笨者手里,任何東西都會弄得一團(tuán)糟。

            c的好處,對我來說,就是可以平鋪直敘,只要設(shè)計(jì)好數(shù)據(jù)結(jié)構(gòu),就可以寫算法了,很簡單。c++這些有oo的語言里面,你卻需要去做一些OO設(shè)計(jì),但是如果設(shè)計(jì)好了,那就很舒服了,因?yàn)樗屑?xì)節(jié)都被遮擋住了。

            在我學(xué)習(xí)的那么多語言中,各種語言有各種語言的特色特點(diǎn),同樣也有他們的缺點(diǎn)。語言本身沒有錯(cuò),存在的就是有理的。錯(cuò)的,永遠(yuǎn)都是使用語言的人。

            工欲善其事,必先利其器。沒有那把金剛鉆,就不要攬那瓷器活。  回復(fù)  更多評論   

            # re: C++雜談 2011-07-11 21:57 pangzi

            auto_ptr<int*>,細(xì)節(jié)是魔鬼,尤其是寫C++程序。  回復(fù)  更多評論   

            # re: C++雜談 2011-07-11 22:42 放屁阿狗

            我考慮用c++無非是執(zhí)行性能和寫代碼可以偷懶(比c),其他場景用腳本比較多  回復(fù)  更多評論   

            # re: C++雜談 2011-07-12 08:51 華夏之火

            在下并不畏懼用C來開發(fā),C的細(xì)節(jié)并不多,大部分語句,本人已有其對應(yīng)的匯編代碼的條件反射。在下對BOOST也沒有嗤之以鼻。實(shí)在不明白閣下怎么對在下的誤解會如此之大@kevin
              回復(fù)  更多評論   

            # re: C++雜談 2011-07-12 09:03 華夏之火

            很有道理,完全贊同。語言自然沒有錯(cuò),用匯編都可以寫出很優(yōu)秀的軟件,更何況是用C,只不過用C來開發(fā),不僅僅只是設(shè)計(jì)數(shù)據(jù)結(jié)構(gòu)和算法,還有更多問題要考慮,C勝在其簡單,敗也在其簡單,當(dāng)然對于高手來說,這些都不是問題。C++自然很復(fù)雜,我相信任何一個(gè)人都可以掌握復(fù)雜的東西,但問題在于要用復(fù)雜的工具來簡化復(fù)雜的問題,而不是使原本就很復(fù)雜的問題變得更加復(fù)雜,至于OO等設(shè)計(jì),不提也罷@楊粼波
              回復(fù)  更多評論   

            # re: C++雜談 2011-07-12 09:07 華夏之火

            只考慮執(zhí)行性能和寫代碼可以偷懶,這種態(tài)度對C++不公平,也會導(dǎo)致一些項(xiàng)目的問題,C++有屬于自己的一套哲學(xué)角度@放屁阿狗
              回復(fù)  更多評論   

            # re: C++雜談 2011-07-12 09:09 華夏之火

            細(xì)節(jié)確實(shí)是魔鬼,用C++開發(fā),一定要花部分精力來專門對付細(xì)節(jié),以方便其他地方,盡量避免接觸細(xì)節(jié)@pangzi
              回復(fù)  更多評論   

            # re: C++雜談[未登錄] 2011-07-12 12:13 tom

            @pangzi
            "auto_ptr<int*>,細(xì)節(jié)是魔鬼"
            You are the best!  回復(fù)  更多評論   

            # re: C++雜談[未登錄] 2011-07-12 17:22 Chipset

            auto_ptr簡直就是垃圾,多CPU環(huán)境怎么并發(fā)?還有,怎么弄個(gè)數(shù)組出來?
            boost架構(gòu)上盡管內(nèi)部耦合很大,但無可厚非是一個(gè)優(yōu)秀的C++庫。
            至于C++教材,50%起到正面作用,50%起到負(fù)面作用,尤其有些像什么譚xx的,簡直就是誤人子弟,除了考試純屬扯淡。  回復(fù)  更多評論   

            # re: C++雜談 2011-07-12 17:44 華夏之火

            這樣指責(zé),有點(diǎn)冤枉auto_ptr了,auto_ptr旨在管理單個(gè)的對象,數(shù)組是其他智能指針的事情,至于多CPU環(huán)境,那對auto_ptr的要求也太高了,很多優(yōu)秀的class都無法勝任。在下沒有說boost不優(yōu)秀。C++教材其實(shí)也很難編的,小強(qiáng)就不要說了,提都不值得提@Chipset
              回復(fù)  更多評論   

            # re: C++雜談[未登錄] 2011-07-13 00:08 kevin

            @華夏之火
            從特定的角度來看文章表述的觀點(diǎn)是沒有問題的。但是沒有考慮在復(fù)雜生產(chǎn)環(huán)境下的情況就把boost甚至C++0X標(biāo)準(zhǔn)拍死了。

            試想一下,在高并發(fā)網(wǎng)絡(luò)服務(wù)器上管理客戶端連接(session),當(dāng)一個(gè)session斷開時(shí),為了保證程序不異常不能立即delete掉session的內(nèi)存,要先遍歷一次消息隊(duì)列,確定沒有這個(gè)session的消息在等待處理才能釋放內(nèi)存,否則把session放到另一個(gè)隊(duì)列等待它的所有消息處理完成后釋放內(nèi)存。想想這里的開銷吧,是很驚人的。如果用shared_ptr來管理session,大可直接將session移出session隊(duì)列,此session的引用計(jì)數(shù)不為0不會被釋放,當(dāng)消息隊(duì)列中session的消息處理完成后引用計(jì)數(shù)歸0,session自動(dòng)delete,安全高效,是不是很爽?

            一個(gè)大項(xiàng)目改動(dòng)一個(gè)類或結(jié)構(gòu)定義引起的連鎖效應(yīng)是很恐怖的,特別是在沒有搞好前置聲明的項(xiàng)目里,改個(gè)定義要把幾乎所有文件重新編譯一編,花十多分鐘的時(shí)間,簡直是個(gè)噩夢。這時(shí)候你會發(fā)現(xiàn)tuple是個(gè)多么美妙的東西。

            functor、any等boost提供的工具都使c++變的更強(qiáng)大。

            。。。越寫越多,再寫就快變成博文了。  回復(fù)  更多評論   

            # re: C++雜談 2011-07-13 09:28 華夏之火

            再次聲明,本人并沒有拍死BOOST,至于看不起C++0X,那更屬子虛烏有(此罪名是否Tuple、share_ptr在TR12中)。每一個(gè)類寫得再不好,都有其應(yīng)用的場合,更何況BOOST中的東西。高并發(fā)網(wǎng)絡(luò)服務(wù)器,用share_ptr管理SESSION,確實(shí)不錯(cuò),但有多少人需要寫高并發(fā)網(wǎng)絡(luò)服務(wù)器的,此種高端的東西,更要有高水平的人來做,相信除了share_ptr,還有更好的方案,比如SESSION POOL。至于tuple,依然無法解決重新編譯的問題,返回tuple的時(shí)候,如果tuple中的類型改變了,所有使用到返回tuple的函數(shù),還不是要重新編譯。@kevin
              回復(fù)  更多評論   

            # re: C++雜談 2011-07-13 11:59 kevin.c

            @華夏之火
            session pool在這里解決不了問題,再仔細(xì)考慮一下吧。
            tuple改變只要重新編譯連接source文件就可以了,引用到header文件的其它類是不受影響的。  回復(fù)  更多評論   

            # re: C++雜談 2011-07-13 12:44 陳良喬——《我的第一本C++書》

            很贊同你的關(guān)于C++教育的觀點(diǎn)
            我就很反對那種孔乙己式的搬弄C++語法細(xì)節(jié)的方式,所以我的書中,只介紹最常用最通用的問題的解決方法,不去向讀者介紹那些所謂的高級技巧

            另外,我的書中也涉及了智能指針,按照你的說法,應(yīng)該算是一本合格的C++書  回復(fù)  更多評論   

            # re: C++雜談 2011-07-13 16:13 華夏之火

            @陳良喬——《我的第一本C++書》
            你的書通俗易懂,非常好,不僅僅合格而已,要是當(dāng)初學(xué)編程時(shí)能看到這樣的書就好了。我的第一本程序書居然是小強(qiáng)的C語言,唉,悲劇……  回復(fù)  更多評論   

            # re: C++雜談[未登錄] 2011-07-14 20:45 cexer

            應(yīng)用的框架到了比較高的階段,所面臨的問題的寬度和深度已經(jīng)完全超越了語言之間的微妙界線,所以像 shared_ptr 這類語言底層的東西,不能拿到這種場合來說。boost 是個(gè)大雜噲,有些東西用起來很不錯(cuò),比如說 shared_ptr,有些東西不是拿來用的,是實(shí)驗(yàn)室產(chǎn)物,像你說的 tuple 確實(shí)是不大實(shí)用。
            上面有人竟然拿 auto_ptr 來說多 CPU 并發(fā)。這種問題就好像,你在路上撿到一塊鼠標(biāo)墊,然后就開始發(fā)愁,還配點(diǎn)啥才能玩上魔獸世界。  回復(fù)  更多評論   

            # re: C++雜談 2011-07-15 08:49 華夏之火

            @cexer
            高手啊!只是近來頗為反感BOOST中的種種精巧的玩意,搞得大部分人對C++望而生畏。其實(shí)不搞花招,完全可以用C++寫出非常清晰的代碼。只要用上了花招,我就會懷疑那些代碼的設(shè)計(jì)是否有問題,有必要那樣拐彎抹角嗎  回復(fù)  更多評論   

            # re: C++雜談 2011-07-17 18:34 nohacler

            @陳良喬——《我的第一本C++書》
            很幸運(yùn)這本書算是我的第一本......其實(shí)我是看到很多注解才買的要不我就買小強(qiáng)的了 那就要杯具了  回復(fù)  更多評論   

            # re: C++雜談 2011-09-14 14:38 ToddChan

            不思進(jìn)取  回復(fù)  更多評論   

            # re: C++雜談 2012-05-25 21:23 幻の上帝

            博主閱讀水平或眼界堪憂……
            《我的第一本C++書》比譚X好不了多少,在CU上早就被吐槽成蜂窩了。。。
              回復(fù)  更多評論   

            # re: C++雜談 2013-11-18 17:59 歲月漫步

            寫的很好  回復(fù)  更多評論   

            # re: C++雜談 2014-12-06 23:04 hancmhi

            auto_ptr<int*> pa(new int) 是這樣的嗎?  回復(fù)  更多評論   


            只有注冊用戶登錄后才能發(fā)表評論。
            網(wǎng)站導(dǎo)航: 博客園   IT新聞   BlogJava   博問   Chat2DB   管理


            導(dǎo)航

            統(tǒng)計(jì)

            常用鏈接

            留言簿(6)

            隨筆分類

            隨筆檔案

            搜索

            積分與排名

            最新評論

            閱讀排行榜

            評論排行榜

            丁香久久婷婷国产午夜视频| 2021国产精品久久精品| 久久国产精品国产自线拍免费| 99久久精品毛片免费播放| 88久久精品无码一区二区毛片| 精品久久久久国产免费| 久久人人爽人人爽人人片AV不 | 精品久久人人爽天天玩人人妻| 久久精品国产亚洲AV嫖农村妇女 | 精品永久久福利一区二区| 久久精品中文字幕有码| 77777亚洲午夜久久多喷| 人妻少妇精品久久| 久久免费精品视频| 午夜精品久久久久久99热| 久久精品国产一区二区电影| 久久99精品久久久久久久不卡| 区亚洲欧美一级久久精品亚洲精品成人网久久久久 | 人妻系列无码专区久久五月天| 91精品国产91久久综合| 亚洲色大成网站www久久九 | 久久99国内精品自在现线| 亚洲精品视频久久久| 国产综合成人久久大片91| 国内精品久久久人妻中文字幕| 中文字幕热久久久久久久| 亚洲欧美日韩精品久久亚洲区 | 一本一本久久a久久综合精品蜜桃| 国产亚洲成人久久| 国产成人综合久久久久久| 日本福利片国产午夜久久| 浪潮AV色综合久久天堂| 国产69精品久久久久久人妻精品| 久久综合精品国产一区二区三区| 久久青青草原精品国产软件| 久久中文精品无码中文字幕| 无夜精品久久久久久| 久久人人青草97香蕉| 国产偷久久久精品专区| 色狠狠久久AV五月综合| 久久国产精品久久久|