• <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 華夏之火 閱讀(3764) 評(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://www.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)論排行榜

            亚洲欧洲中文日韩久久AV乱码| 99久久国产热无码精品免费久久久久| 伊人丁香狠狠色综合久久| 99久久精品国产麻豆| 亚洲综合久久综合激情久久| 精品视频久久久久| 色播久久人人爽人人爽人人片AV| 超级碰碰碰碰97久久久久| 久久99国产精品一区二区| 久久不见久久见免费影院www日本| 久久一本综合| 国产成人久久激情91| 婷婷久久综合九色综合绿巨人| 99久久国产宗和精品1上映| 久久国产精品-国产精品| 香蕉久久夜色精品国产2020| 无码人妻少妇久久中文字幕蜜桃| 精品久久人人做人人爽综合 | 国产69精品久久久久99尤物 | 久久99精品久久久久久久不卡| 国产成人综合久久综合| 久久99热这里只频精品6| 97精品国产97久久久久久免费| 狠狠色综合网站久久久久久久高清 | 国产精品久久久久久久午夜片| 狠狠色狠狠色综合久久| 国产亚洲精午夜久久久久久| 新狼窝色AV性久久久久久| 一级a性色生活片久久无| 91精品观看91久久久久久 | 亚洲国产精品久久久久婷婷软件 | 少妇高潮惨叫久久久久久| 久久综合五月丁香久久激情| 久久久精品午夜免费不卡| 国内精品久久久久影院亚洲| 国内精品久久久久久久涩爱| 久久这里只有精品首页| 色综合久久久久网| 久久国产乱子伦精品免费强| 久久精品一本到99热免费| 久久久久久亚洲AV无码专区|