青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品

huaxiazhihuo

 

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

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

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

評論

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

導航

統(tǒng)計

常用鏈接

留言簿(6)

隨筆分類

隨筆檔案

搜索

積分與排名

最新評論

閱讀排行榜

評論排行榜

青青草原综合久久大伊人导航_色综合久久天天综合_日日噜噜夜夜狠狠久久丁香五月_热久久这里只有精品
  • <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>
            在线视频你懂得一区| 亚洲一区二区在线免费观看视频| 久久久久国产免费免费| 亚洲综合精品一区二区| 亚洲专区在线视频| 性欧美xxxx大乳国产app| 欧美在线网址| 欧美mv日韩mv国产网站app| 欧美大学生性色视频| 欧美视频中文在线看| 国产欧美一区二区精品仙草咪| 国产免费成人| 在线免费观看日本欧美| 一区二区三区日韩欧美| 久久都是精品| 亚洲国产精品va在线看黑人| 亚洲美女中出| 午夜精品福利电影| 久久精品一级爱片| 亚洲成人在线视频播放| 欧美mv日韩mv国产网站| 亚洲精品视频在线播放| 欧美一区二区三区在线| 欧美大片在线观看| 国产欧美日韩另类一区| 亚洲日韩欧美视频一区| 久久国产福利| 99精品国产热久久91蜜凸| 久久狠狠一本精品综合网| 欧美精品一区二区久久婷婷| 国产日韩欧美综合一区| 一区二区精品| 欧美二区不卡| 欧美中文字幕在线播放| 欧美三级资源在线| 91久久国产综合久久| 久久精品国产亚洲一区二区| 亚洲乱码视频| 男人插女人欧美| 韩国女主播一区| 午夜精品一区二区在线观看| 最新日韩精品| 美女精品国产| 黄色成人91| 久久精品观看| 午夜精品久久久久久久99樱桃 | 亚洲欧美日韩专区| 亚洲国产免费看| 久久九九电影| 国产综合欧美| 久久精品一本| 午夜欧美大尺度福利影院在线看 | 亚洲丰满在线| 久久久久久国产精品mv| 亚洲欧美精品一区| 国产精品免费看久久久香蕉| 亚洲图片在线观看| 99re热精品| 欧美视频专区一二在线观看| 在线视频欧美日韩精品| 99在线热播精品免费| 欧美性生交xxxxx久久久| 亚洲一区二区三区视频播放| 一区二区三区日韩| 国产精品欧美经典| 欧美在线高清视频| 久久精品国产精品亚洲精品| 一区在线视频观看| 久久午夜激情| 久久综合久久美利坚合众国| 在线观看精品视频| 欧美激情精品久久久久久| 久久米奇亚洲| 99视频精品| 国产精品伦子伦免费视频| 亚洲在线一区二区| 亚洲一区二区三区免费在线观看| 国产精品久久久久久久一区探花| 销魂美女一区二区三区视频在线| 亚洲一区二区在线看| 国产亚洲欧美一区| 欧美不卡高清| 欧美女同在线视频| 性久久久久久久久| 欧美一区二视频| 最近中文字幕mv在线一区二区三区四区| 欧美激情麻豆| 国产精品久久看| 麻豆精品传媒视频| 欧美人与禽性xxxxx杂性| 午夜在线一区| 久久久爽爽爽美女图片| 中日韩美女免费视频网站在线观看| 亚洲一区二区三区777| 激情欧美一区二区三区在线观看| 亚洲欧洲精品一区二区三区不卡 | 欧美视频二区| 久久综合国产精品| 欧美日韩国产综合一区二区| 久久精品国产精品亚洲精品| 欧美阿v一级看视频| 欧美亚洲在线观看| 欧美福利视频在线| 久久久国产精品一区二区三区| 欧美福利网址| 久久深夜福利免费观看| 国产精品国产三级国产普通话蜜臀| 玖玖玖国产精品| 国产精品久久77777| 亚洲高清不卡| 一区二区三区亚洲| 亚洲欧美成人网| 亚洲视频在线观看三级| 老司机久久99久久精品播放免费 | 亚洲一区二区三区高清| 久久久久国产一区二区三区四区| 亚洲一级在线观看| 欧美不卡一区| 蜜臀a∨国产成人精品| 国产欧美短视频| 一本一本久久a久久精品综合妖精 一本一本久久a久久精品综合麻豆 | 久久经典综合| 亚洲欧美日韩国产成人| 欧美国产一区二区| 欧美成人午夜影院| 永久免费视频成人| 欧美中在线观看| 先锋影音国产精品| 欧美高清在线观看| 日韩一级不卡| 亚洲国产三级在线| 久久国产精品久久久久久久久久| 国产精品女人网站| 国产精品theporn| 欧美日韩国产成人在线91| 国产日韩欧美高清免费| 欧美一区成人| 欧美/亚洲一区| 久久亚洲精品视频| 韩国视频理论视频久久| 久久精品成人| 裸体一区二区三区| 亚洲高清免费| 欧美96在线丨欧| 亚洲国产人成综合网站| 亚洲精品社区| 欧美精品一区二区蜜臀亚洲| 亚洲日本精品国产第一区| 一本一本久久a久久精品综合妖精 一本一本久久a久久精品综合麻豆 | 国产亚洲综合精品| 欧美在线精品一区| 麻豆成人综合网| 亚洲日本电影在线| 欧美精品91| 亚洲一区三区电影在线观看| 欧美在线视频免费播放| 悠悠资源网亚洲青| 欧美国产精品va在线观看| 99re66热这里只有精品3直播| 亚洲中字在线| 国产一区二区三区在线观看精品| 久久综合综合久久综合| 亚洲美女视频网| 欧美在线免费| 亚洲激情婷婷| 国产精品视频免费| 久久久免费精品| 99综合电影在线视频| 久久久久久久91| 一本色道久久综合| 国产综合18久久久久久| 欧美日韩国产成人在线观看| 久久se精品一区精品二区| 亚洲国产一区在线| 亚洲欧美一区二区精品久久久| 国产在线观看91精品一区| 欧美激情bt| 香蕉国产精品偷在线观看不卡| 亚洲电影av| 欧美在线综合视频| 99成人免费视频| 国内精品视频666| 欧美视频一区二区三区…| 久久精品国产精品亚洲| 一区二区三区免费网站| 免费欧美电影| 久久久精品午夜少妇| 亚洲网站在线看| 亚洲国产日韩欧美在线99| 亚洲精品人人| 韩国三级在线一区| 国产精品国产三级国产普通话99 | 葵司免费一区二区三区四区五区| aa级大片欧美三级| 亚洲国产精品久久人人爱蜜臀 | 久久精品中文字幕一区二区三区| 亚洲伦理在线免费看| 国内免费精品永久在线视频| 欧美日韩国产一级| 欧美成人精品不卡视频在线观看|