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

                    對于C++,沒什么好說的。但C++的教育,就有太多的不滿,要指責之處,也實在太多了,其中最為人詬病,就是很多C++的教材,都鼓勵讀者將注意力集中到C++的細節中,而忘記了如何用C++來簡潔質樸地來表達設計思路。關于這一點,很多達人君子也已經一再嚴厲地批評再批評。我也不想重復他們的論調,只想舉兩個例子。

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

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

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

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

            評論

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

            90%贊同,感同身受,,,  回復  更多評論   

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

            那是因為你不懂得使用Boost,標準委員會幾千人的結晶就被你一句話否決了
            好好學一學吧 你太依賴auto_ptr了  回復  更多評論   

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

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

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

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

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

            代碼還是實用點,簡單點的好。  回復  更多評論   

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

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

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

            大多數的內存泄漏,都是設計上的缺陷@fx
              回復  更多評論   

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

            這篇文章只是暴露出了你的弱點。因為不能掌握C的細節而畏懼,對BOOST不了解而對其嗤之以鼻。C++因為先天缺陷其最大的障礙是如何對問題解偶,BOOST在這方面是典范,不僅提供了一系列的解偶工具,其本身也是一個很好的范例。多花點時間磨練一下自己吧。  回復  更多評論   

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

            一切遵循木桶效應,如果項目中有一兩個水平低的,那么整個項目的質量都可能會被這一兩個人所拖累。

            如果一個人,掌握不了復雜的東西。風險最小原則,那么就不要使用復雜的東西,那將會把一切都搞砸掉。

            不論是什么語言,什么技術,在技藝好的人手里,都能玩轉自如,而在一個初學者,一個愚笨者手里,任何東西都會弄得一團糟。

            c的好處,對我來說,就是可以平鋪直敘,只要設計好數據結構,就可以寫算法了,很簡單。c++這些有oo的語言里面,你卻需要去做一些OO設計,但是如果設計好了,那就很舒服了,因為所有細節都被遮擋住了。

            在我學習的那么多語言中,各種語言有各種語言的特色特點,同樣也有他們的缺點。語言本身沒有錯,存在的就是有理的。錯的,永遠都是使用語言的人。

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

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

            auto_ptr<int*>,細節是魔鬼,尤其是寫C++程序。  回復  更多評論   

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

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

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

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

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

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

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

            只考慮執行性能和寫代碼可以偷懶,這種態度對C++不公平,也會導致一些項目的問題,C++有屬于自己的一套哲學角度@放屁阿狗
              回復  更多評論   

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

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

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

            @pangzi
            "auto_ptr<int*>,細節是魔鬼"
            You are the best!  回復  更多評論   

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

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

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

            這樣指責,有點冤枉auto_ptr了,auto_ptr旨在管理單個的對象,數組是其他智能指針的事情,至于多CPU環境,那對auto_ptr的要求也太高了,很多優秀的class都無法勝任。在下沒有說boost不優秀。C++教材其實也很難編的,小強就不要說了,提都不值得提@Chipset
              回復  更多評論   

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

            @華夏之火
            從特定的角度來看文章表述的觀點是沒有問題的。但是沒有考慮在復雜生產環境下的情況就把boost甚至C++0X標準拍死了。

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

            一個大項目改動一個類或結構定義引起的連鎖效應是很恐怖的,特別是在沒有搞好前置聲明的項目里,改個定義要把幾乎所有文件重新編譯一編,花十多分鐘的時間,簡直是個噩夢。這時候你會發現tuple是個多么美妙的東西。

            functor、any等boost提供的工具都使c++變的更強大。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

            不思進取  回復  更多評論   

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

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

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

            寫的很好  回復  更多評論   

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

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

            導航

            統計

            常用鏈接

            留言簿(6)

            隨筆分類

            隨筆檔案

            搜索

            積分與排名

            最新評論

            閱讀排行榜

            評論排行榜

            亚洲国产精品综合久久一线| 亚洲午夜精品久久久久久人妖| 久久久噜噜噜久久中文字幕色伊伊| 无码8090精品久久一区| 亚洲国产日韩综合久久精品| 久久久久亚洲av无码专区导航| 久久精品中文字幕久久| 无码精品久久一区二区三区 | 久久久久久A亚洲欧洲AV冫| 久久精品国产精品亜洲毛片| 99久久夜色精品国产网站| 91精品国产91久久久久久青草| 蜜桃麻豆WWW久久囤产精品| 久久国产免费观看精品| 一本大道久久香蕉成人网| 久久精品国产99国产精偷| 久久久久久精品成人免费图片| 91性高湖久久久久| 国产成人精品白浆久久69| 少妇熟女久久综合网色欲| 大蕉久久伊人中文字幕| 久久国产精品久久国产精品| 亚洲愉拍99热成人精品热久久| 久久婷婷五月综合色99啪ak| 色综合色天天久久婷婷基地 | 久久99精品国产麻豆宅宅| 一本一道久久a久久精品综合| 国产高清美女一级a毛片久久w | 99久久国产亚洲高清观看2024| 亚洲国产精品无码久久久秋霞2| 麻豆久久| 亚洲国产成人乱码精品女人久久久不卡 | 精品久久久久久久国产潘金莲| 国内精品久久久久久久涩爱| 国产欧美久久久精品| 久久人人爽爽爽人久久久| 伊人久久精品无码av一区| 亚洲国产精品无码成人片久久| 亚洲精品国产综合久久一线| 久久受www免费人成_看片中文| 久久久久九国产精品|