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

             

            難以割舍的二段構(gòu)造

                    兩段構(gòu)造也是聲名狼藉得很,比之于MFC,好不了多少,貌似MFC中到處都是兩段構(gòu)造,難道兩段構(gòu)造的聲譽(yù)也是受MFC所累。定義完了一個(gè)對(duì)象變量之后,還要再調(diào)用一次該對(duì)象的Create函數(shù),而且還要Create成功了之后,才能對(duì)該對(duì)象做進(jìn)一步的操作,否則對(duì)象將一直處于非法狀態(tài)。這種代碼方式寫起來確實(shí)很惡心,為何不直接在構(gòu)造函數(shù)中直接Create,不成功就拋出異常,然后對(duì)象就流產(chǎn)了,好過它半死不活地一直茍延殘喘于世上,累己累人。其實(shí),MFC選擇兩段構(gòu)造也是有苦衷:1、先是很久很久以前,VC編譯器對(duì)異常的支持不怎么好,當(dāng)然,現(xiàn)在的VC編譯器,自然今時(shí)不比往日,但是,還要兼容以往的代碼;2、然后是MFC的設(shè)計(jì),它只是對(duì)API做了一層薄薄的包裝,薄薄的意思,就是,不管怎么搗鼓,都難以將WINDOWS系統(tǒng)中的各種對(duì)象包裝成一個(gè)干凈的C++對(duì)象了,因?yàn)椋珹PI本身就采用兩段構(gòu)造。可不是嗎?定義一個(gè)句柄變量,然后CreateXXX返回結(jié)果,返回值非法,表示創(chuàng)建失敗。失敗了,還要霸王硬上弓,后果會(huì)怎么樣,這誰也不知道。
                    理論上,構(gòu)造函數(shù)拋出異常確實(shí)很優(yōu)雅,代碼也更具美感,并且,其行為也更加明確,要么就處理,要么,就等著程序異常退出。但是,實(shí)際上,異常這種東西,真正實(shí)現(xiàn)執(zhí)行起來,卻相當(dāng)?shù)睦щy。更何況,如果完全丟棄兩段法,除了異常,還會(huì)引入一些新的問題,正所謂:“前門驅(qū)虎,后門進(jìn)狼”,進(jìn)來不只是一只狼,而是好幾只。生活的奧妙,就在于制造出新的問題,以解決舊的問題。
                    構(gòu)造函數(shù)中直接調(diào)用Create,就表示了用戶一定義一個(gè)類型變量,程序就會(huì)馬上啟動(dòng)Create函數(shù),也就意味著可能將創(chuàng)建窗口對(duì)象、內(nèi)核對(duì)象、甚至啟動(dòng)新的線程等等,這些操作都不是省油的燈,構(gòu)造函數(shù)中做了太多事情,會(huì)有隱藏太多細(xì)節(jié)之嫌,代碼本來就是為了隱藏細(xì)節(jié),這個(gè)多事之罪名暫且不論;但是,用戶沒法對(duì)創(chuàng)建過程Say NOT,也即是說,用戶一定義對(duì)象變量,就只能接受它的高昂的創(chuàng)建過程。難道,一開始就讓對(duì)象進(jìn)入有效狀態(tài),這都有錯(cuò)嗎?確實(shí)是的。有時(shí)候,用戶只是先想聲明(定義)對(duì)象,等必要(時(shí)機(jī)成熟)的時(shí)候,再讓它進(jìn)入有效狀態(tài)。咦,用戶這樣寫代碼,不太好吧,應(yīng)該強(qiáng)制他/她等到了那個(gè)時(shí)候,再定義對(duì)象變量。變量怎么可以隨隨便便就定義呢?應(yīng)該在要使用的時(shí)候,才定義它,這才是良好的代碼風(fēng)格。但是,有些情況,確實(shí)需要先暫時(shí)定義非法狀態(tài)下的對(duì)象變量,比如,這個(gè)對(duì)象是另一個(gè)對(duì)象(擁有者)的成員變量時(shí),那也沒什么,強(qiáng)制用戶在必要的時(shí)候,才定義擁有者對(duì)象變量。但是,假如這個(gè)擁有者必須是全局變量,那該怎么辦?那也沒什么,將擁有者定義為指針變量就是了?好了,本來只是要對(duì)象創(chuàng)建失敗的情況,現(xiàn)在還要考慮內(nèi)存分配的細(xì)節(jié),然后接著就是new delete,然后就是各種智能指針閃亮登臺(tái)演出,更糟糕的是,對(duì)象有效無效的問題依然沒有根除,因?yàn)椋灰胫羔槪看问褂弥羔槪捅仨殭z查指針是否有效,咦,難道操作空指針不會(huì)拋出異常嗎?C++規(guī)范中,操作空指針屬后果未確定的行為,對(duì)C++而言,未確定往往就是最糟糕的意思。此外,鑒于對(duì)象只能一直處于有效狀態(tài),它就不可能提供讓對(duì)象進(jìn)入無效狀態(tài)的操作。如果想要讓對(duì)象無效,唯一的辦法,就是讓它死去,強(qiáng)制對(duì)象啟動(dòng)析構(gòu)函數(shù),方法是離開作用域強(qiáng)者delete它。下次要使用它的時(shí)候,就再new一次或者定義一次,不,它已經(jīng)是另外一條新生命了。但是,對(duì)于兩段構(gòu)造的對(duì)象,只須Destroy又或者Create,對(duì)象可以永遠(yuǎn)只有一個(gè)。此外,二段構(gòu)造頗具擴(kuò)展性,很輕易地就可搞成三段構(gòu)造,每一步,用戶都有選擇的權(quán)利。但構(gòu)造異常就沒有這個(gè)優(yōu)點(diǎn)。
                    考慮到構(gòu)造函數(shù)中的參數(shù)問題,比如,月份的參數(shù),大家都知道,有效值只在1-12月之間。不討論這種情況下,非法的參數(shù)傳遞是否屬于代碼的邏輯問題。對(duì)此,構(gòu)造異常指導(dǎo)下的對(duì)象是不可能出現(xiàn)無參(沒有參數(shù)或者參數(shù)都有缺省值)的構(gòu)造函數(shù),因此,它們也都不能用于數(shù)組,難以應(yīng)用于全局變量、靜態(tài)變量、作為其他對(duì)象的數(shù)據(jù)成員,如果非要在這些場合下使用它們,比如占位符的作用,唯有用上指針,于是伴隨而來的,又如上文所述,使用指針之前,必須檢查指針的有效性,只怕不會(huì)比檢查二段構(gòu)造的有效性好多少。
                    二段構(gòu)造不輕易剝奪用戶的權(quán)利,提供更多選擇,可用于數(shù)組、堆棧、STL中的容器,要它死,它就死,要它活,它就活,但是,它可以從來都未曾消失過,要做的,僅僅是在使用它時(shí),清楚它是死是活就行了,不過多加幾次判斷而已。相比之下,構(gòu)造異常就更具侵入性了,一旦用上,就只能被迫遵照它的規(guī)則行事。
                    其實(shí),兩段構(gòu)造與構(gòu)造異常,都很惡心,只要一處代碼中用到了它,所有與之相關(guān)的代碼都沒法脫身。差別不過在于誰比誰惡心而已,這個(gè),視各人的口味而不同。對(duì)于本人這種害怕分配內(nèi)存,釋放內(nèi)存,更加畏懼異常的人來說(這并不表示本人寫不出異常安全的代碼),當(dāng)然優(yōu)先選擇二段構(gòu)造,MORE EFFECTIVE的條款中,聲稱,如無必要,不要提供缺省的構(gòu)造函數(shù),以免對(duì)象陷入半死不活的狀態(tài)中。而我的習(xí)慣作法則是,如無必要,必須提供缺省的構(gòu)造函數(shù),不要輕易剝奪用戶想要使用對(duì)象數(shù)組的權(quán)利,或者是由于不提供缺省的構(gòu)造函數(shù),而由此引起的種種不便。
                    好了,既然程序中決定用二段構(gòu)造了,那么,假如用戶定義了一個(gè)對(duì)象,忘了再構(gòu)造一次,但是又要執(zhí)行其他操作,怎么辦?嗯,那也沒什么,既然用戶不遵守契約,我們的對(duì)象自然可以做出種種不確定的行為。當(dāng)然,別忘了,在其他的每一個(gè)操作上都添加幾條assert語句,盡管這很惡心,也聊勝于無,減少點(diǎn)罪惡感,以便于在調(diào)試版中找出問題。

            posted on 2012-06-14 15:08 華夏之火 閱讀(3766) 評(píng)論(14)  編輯 收藏 引用 所屬分類: c++技術(shù)探討

            評(píng)論

            # re: 難以割舍的二段構(gòu)造 2012-06-14 16:37 Richard Wei

            支持一下,C++里我們一般把分配內(nèi)存和簡單的初始化工作都放在了構(gòu)造函數(shù)里,而把一些復(fù)雜的工作放在一個(gè)單獨(dú)的初始化函數(shù)里,這樣的話比較靈活。如果覺得使用不方便,可以自己封裝一層,也就是所謂的RAII了。  回復(fù)  更多評(píng)論   

            # re: 難以割舍的二段構(gòu)造 2012-06-14 17:45 華夏之火

            是啊,在下也偏向于精簡構(gòu)造函數(shù)。對(duì)于多事的構(gòu)造函數(shù)的代碼,內(nèi)心總是很排斥,本能的對(duì)于細(xì)節(jié)的感興趣,或者這也是C++者們的通病@Richard Wei
              回復(fù)  更多評(píng)論   

            # re: 難以割舍的二段構(gòu)造 2012-06-14 18:35 春秋十二月

            http://m.shnenglu.com/qinqing1984/archive/2011/07/04/150084.html  回復(fù)  更多評(píng)論   

            # re: 難以割舍的二段構(gòu)造 2012-06-14 20:41 華夏之火

            ?這些都是深度探索c++對(duì)象模型中的內(nèi)容,每一個(gè)想在c++上有所作為的人必須先深度探索這本書。@春秋十二月  回復(fù)  更多評(píng)論   

            # re: 難以割舍的二段構(gòu)造 2012-06-15 11:25 guilin

            有時(shí)候,用戶只是先想聲明(定義)對(duì)象,等必要(時(shí)機(jī)成熟)的時(shí)候,再讓它進(jìn)入有效狀態(tài)
            這是你不用異常的基礎(chǔ)論點(diǎn)。絕對(duì)不應(yīng)該出現(xiàn)這種用法,所以整篇文章都是扯淡  回復(fù)  更多評(píng)論   

            # re: 難以割舍的二段構(gòu)造 2012-06-15 11:33 guilin


            “有時(shí)候,用戶只是先想聲明(定義)對(duì)象,等必要(時(shí)機(jī)成熟)的時(shí)候,再讓它進(jìn)入有效狀態(tài)。”
            這正是二段構(gòu)造的用法。
            你說構(gòu)造+異常的用法不好的理由卻是:“有時(shí)想使用二段構(gòu)造。”……
            這就像為什么不開車:因?yàn)橛袝r(shí)候想走路,所以開車不好。  回復(fù)  更多評(píng)論   

            # re: 難以割舍的二段構(gòu)造 2012-06-15 11:42 華夏之火

            在下也知道不應(yīng)該這樣用,只是碰到這樣的需求,該怎么辦,難道要用指針嗎?@guilin
              回復(fù)  更多評(píng)論   

            # re: 難以割舍的二段構(gòu)造 2012-06-15 16:44 guilin

            @華夏之火
            我從來沒碰到這樣的需求,你可以舉個(gè)簡單例子出來看看  回復(fù)  更多評(píng)論   

            # re: 難以割舍的二段構(gòu)造 2012-06-15 17:13 華夏之火

            好比一個(gè)服務(wù)器類,我們一般都是先定義一個(gè)對(duì)象變量,然后讓變量開始監(jiān)聽端口并啟動(dòng)監(jiān)聽的線程,這也可以看成二段構(gòu)造吧。難道你要定義服務(wù)器對(duì)象的時(shí)候,就讓它在構(gòu)造函數(shù)里面直接就開始監(jiān)聽并啟動(dòng)線程嗎@guilin
              回復(fù)  更多評(píng)論   

            # re: 難以割舍的二段構(gòu)造 2012-06-17 17:57 guilin

            @華夏之火
            這很正常,可以看看boost asio的幾個(gè)例子,都是在構(gòu)造函數(shù)中干的  回復(fù)  更多評(píng)論   

            # re: 難以割舍的二段構(gòu)造 2012-06-17 18:00 guilin

            @華夏之火
            類成員對(duì)象初始化在初始化列表中已經(jīng)初始化完成了。C++構(gòu)造函數(shù)其實(shí)本質(zhì)上就是一個(gè)init函數(shù),只不過沒有返回值。有了異常,也算有返回值了。所以再多寫一個(gè)init函數(shù)實(shí)在沒有必要  回復(fù)  更多評(píng)論   

            # re: 難以割舍的二段構(gòu)造 2012-06-18 08:59 華夏之火

            受教了,可能是在下內(nèi)心對(duì)于異常的排斥,所以總是要盡量避免這個(gè)東西@guilin
              回復(fù)  更多評(píng)論   

            # re: 難以割舍的二段構(gòu)造 2012-07-09 16:12 哥沒注冊(cè)

            糾結(jié)了
            關(guān)于C++從C上擴(kuò)展出來的這類功能。有益則用,無益就不理會(huì)。比如鄙人基本不使用NEW/DELETE,也就沒有你的困惑了。HOHO~~  回復(fù)  更多評(píng)論   

            # re: 難以割舍的二段構(gòu)造 2012-07-09 17:11 華夏之火

            NEW/DELETE的問題不大,主要是某些較耗資源的玩意,好比線程、文件、數(shù)據(jù)庫連接,直接在構(gòu)造函數(shù)中啟動(dòng),會(huì)讓人很糾結(jié),覺得隱藏太多細(xì)節(jié)@哥沒注冊(cè)
              回復(fù)  更多評(píng)論   

            導(dǎo)航

            統(tǒng)計(jì)

            常用鏈接

            留言簿(6)

            隨筆分類

            隨筆檔案

            搜索

            積分與排名

            最新評(píng)論

            閱讀排行榜

            評(píng)論排行榜

            中文字幕一区二区三区久久网站| 91久久精品国产免费直播| 久久精品无码一区二区app| 久久99精品久久久久久秒播| 欧美粉嫩小泬久久久久久久| 久久WWW免费人成一看片| 欧美日韩精品久久久久| 99久久99久久精品国产片| 精品久久久无码中文字幕| 无夜精品久久久久久| 精品少妇人妻av无码久久| 久久精品不卡| 国产综合久久久久久鬼色| 久久久久亚洲精品无码网址| 天天躁日日躁狠狠久久| 久久久久亚洲AV成人网人人网站 | 狠狠色丁香久久婷婷综| 久久一本综合| 国产精品久久毛片完整版| 亚洲欧美一区二区三区久久| 久久精品人人做人人爽电影| 久久久久久精品久久久久| 国产精品99久久不卡| 人人狠狠综合久久亚洲婷婷| 99久久免费国产精精品| 午夜精品久久久久久久| 亚洲精品高清一二区久久| 久久精品成人欧美大片| 99久久久国产精品免费无卡顿| 一本一本久久a久久精品综合麻豆| 一本伊大人香蕉久久网手机| 麻豆AV一区二区三区久久 | 国产精品久久久久久一区二区三区| 狠狠色丁香婷婷久久综合| 色99久久久久高潮综合影院| 久久久久国产一区二区三区| 国产精品一区二区久久精品无码| 26uuu久久五月天| 久久综合一区二区无码| 久久人人爽人人澡人人高潮AV | 久久久久久国产精品无码超碰|