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

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

            評論

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

            導(dǎo)航

            統(tǒng)計

            常用鏈接

            留言簿(6)

            隨筆分類

            隨筆檔案

            搜索

            積分與排名

            最新評論

            閱讀排行榜

            評論排行榜

            青青草原综合久久大伊人导航 | 伊人久久大香线焦AV综合影院| 久久伊人五月天论坛| 亚洲欧美日韩精品久久亚洲区| 伊人久久大香线蕉综合Av| 久久国产精品77777| 久久精品国产亚洲精品| 久久亚洲欧美国产精品| 久久99精品久久久久久噜噜| 狠狠色婷婷久久综合频道日韩| 久久99国产精品久久99| 久久久这里只有精品加勒比| 好属妞这里只有精品久久| 亚洲人成网站999久久久综合| 国产精品久久永久免费| 精产国品久久一二三产区区别| 日韩精品国产自在久久现线拍| 午夜精品久久久久久99热| 久久精品成人免费观看97| 久久亚洲高清观看| 国内精品久久久人妻中文字幕| 成人综合久久精品色婷婷| 国产精品伊人久久伊人电影| 久久久久亚洲AV无码永不| 一本久久a久久精品亚洲| 中文字幕无码久久久| 久久久久亚洲AV成人网| 国内精品久久久久久麻豆| 国产精品VIDEOSSEX久久发布 | 亚洲性久久久影院| 久久激情亚洲精品无码?V| 国产一区二区精品久久岳| AA级片免费看视频久久| segui久久国产精品| 久久99精品久久久久久噜噜| 国内精品久久久久久久久| 亚洲一本综合久久| AA级片免费看视频久久| 久久精品无码专区免费| 亚洲人AV永久一区二区三区久久 | 香蕉久久夜色精品升级完成|