More Effective C++：防止资源泄漏
2008-03-08 12:40:42 来源：WEB开发网 闂傚倸鍊搁崐鎼佸磹閹间礁纾归柟闂寸绾惧綊鏌熼梻瀵割槮缁炬儳缍婇弻鐔兼⒒鐎靛壊妲紒鎯у⒔閹虫捇鈥旈崘顏佸亾閿濆簼绨绘い鎺嬪灪閵囧嫰骞囬姣挎捇鏌熸笟鍨妞ゎ偅绮撳畷鍗炍旈埀顒勭嵁婵犲嫮纾介柛灞捐壘閳ь剛鎳撻～婵嬪Ω閳轰胶鐤呯紓浣割儐椤戞瑩宕ョ€ｎ喗鐓曟い鎰靛亝缁舵氨绱撻崘鈺傜婵﹤顭峰畷鎺戔枎閹搭厽袦婵犵數濮崑鎾绘⒑椤掆偓缁夌敻骞嗛悙鍝勭婵烇綆鍓欐俊鑲╃磼閹邦収娈滈柡灞糕偓鎰佸悑閹肩补鈧尙鏁栧┑鐐村灦閹稿摜绮旈悽绋课﹂柛鏇ㄥ灠閸愨偓濡炪倖鍔﹀鈧繛宀婁邯濮婅櫣绱掑Ο璇茶敿闂佺ǹ娴烽弫璇差嚕婵犳碍鏅插璺猴工瀹撳棝姊虹紒妯哄缂佷焦鎸冲畷鎴﹀箻鐠囧弶宓嶅銈嗘尰缁嬫垶绂嶉悙顒佸弿婵☆垳鍘ф禍楣冩倵濮樼偓瀚�
闂傚倸鍊搁崐鎼佸磹閹间礁纾归柟闂寸绾惧綊鏌熼梻瀵割槮缁炬儳缍婇弻鐔兼⒒鐎靛壊妲紒鎯у⒔閹虫捇鈥旈崘顏佸亾閿濆簼绨奸柟鐧哥秮閺岋綁顢橀悙鎼闂侀潧妫欑敮鎺楋綖濠靛鏅查柛娑卞墮椤ユ艾鈹戞幊閸婃鎱ㄩ悜钘夌；婵炴垟鎳為崶顒佸仺缂佸瀵ч悗顒勬⒑閻熸澘鈷旂紒顕呭灦瀹曟垿骞囬悧鍫㈠幍缂傚倷鐒﹂敋缂佹う鍥ㄧ厓鐟滄粓宕滈敃鍌氱煑闁告劦鐓堝ḿ鏍煕濠靛棗鐝旂憸鏂跨暦閹偊妲炬繛瀵稿Т閵堢ǹ顫忛搹瑙勫珰闁肩⒈鍓涢澶愭⒑閻撳海绉虹紒鐘崇墵楠炲啯銈ｉ崘鈺佲偓濠氭煢濡警妲奸柟鑺ユ礋濮婃椽妫冨☉杈€嗘繝纰樷偓铏枠鐎规洏鍨介幃浠嬪川婵炵偓瀚奸梺鑽ゅ枑閻熴儳鈧氨鍏樺畷顖濈疀濞戞瑧鍘遍梺缁樏壕顓熸櫠閻㈠憡鐓忛柛鈩冾殔閳ь剙婀辩紓鎾寸鐎ｎ亜绐涙繝鐢靛Т鐎氼剟鐛崼銉︹拺缁绢厼鎳庨ˉ宥夋煙濞茶绨芥俊鍙夊姍瀵挳鎮㈤崫鍕ㄥ彏闂傚倸鍊搁崐椋庢濮橆兗缂氱憸宥囧弲闂侀潧鐗嗗ú鐘诲磻閹炬剚娼╂い鎰╁灩缁侇噣姊虹紒妯圭繁闁革綇缍侀悰顕€骞掗幊铏閸┾偓妞ゆ帒鍊绘稉宥夋煥濠靛棙顥犵紒鈾€鍋撻梻鍌氬€搁悧濠勭矙閹达箑姹叉繛鍡楃贩閻熸壋鍫柛顐犲灮閺嗩偊姊洪崫鍕効缂傚秳鐒﹂幈銊╁焵椤掑嫭鐓冮柟顖滃绾偓绻濋埀顒佹綇閵娧呭骄闂佸搫娲ㄩ崰鎾跺姬閳ь剙鈹戦鏂や緵闁告﹢绠栧畷銏ゆ偨閸涘ň鎷虹紓鍌欑劍閿氬┑顕嗙畵閺屾盯骞橀弶鎴濇懙闂佽鍠楄摫婵炵厧绻樻俊鎼佸Χ閸モ晝鏆伴梻鍌欑濠€杈╁垝椤栨粍鏆滈柣鎰摠濞呯姵绻涢幋鐐寸殤缁炬崘鍋愮槐鎾存媴鐠愵垳绱板┑鐐村絻椤曨參鍩€椤掑喚娼愭繛鍙夌墪閻ｇ兘顢楅崘顏冪胺闂傚倷绀侀幉锟犲礉閺囥垹鐤柣妯款嚙缁€鍫熺節闂堟稓澧涚€规洖寮剁换娑㈠箣閻愩劎绱伴梺鍝勬濡鍩為幋锔藉亹閺夊牜鍋勯崢锟犳⒑鏉炴壆鍔嶉柣妤佺矌濡叉劙骞樼€涙ê顎撴繛瀵稿Т椤戝懘骞楅悽鍛娾拺闁革富鍘介崵鈧┑鐐茬湴閸婃繈骞冩ィ鍐╁€婚柦妯侯槺椤斿﹪姊虹憴鍕剹闁告ü绮欏畷鎾绘偨閸涘ň鎷洪梺鑽ゅ枑濠㈡﹢骞冩笟鈧弻锝夊箳閻愮數鏆ら梺璇″枟椤ㄥ﹪鐛弽銊﹀闁稿繐顦扮€氳棄鈹戦悙鑸靛涧缂佹彃娼″畷鏇㈠Χ婢跺﹤鎯為梺閫炲苯澧存慨濠冩そ楠炴牠鎮欏ù瀣壕闁哄稁鍘介崑瀣煟濡灝鍚圭€规挷绶氶悡顐﹀炊閵娧€濮囬梺鍝勬噺閹倿寮婚妸鈺傚亞闁稿本绋戦锟�
濠电姷鏁告慨鐑藉极閸涘﹥鍙忛柣鎴ｆ閺嬩線鏌涘☉姗堟敾闁告瑥绻橀弻锝夊箣閿濆棭妫勯梺鍝勵儎缁舵岸寮诲☉妯锋婵鐗婇弫楣冩⒑閸涘﹦鎳冪紒缁樺灴婵＄敻宕熼姘鳖啋闂佸憡顨堥崑鐔哥閼测晝纾藉ù锝呮惈椤庡矂鏌涢妸銉у煟鐎殿喛顕ч埥澶愬閻樼數鏉搁梻鍌氬€搁悧濠勭矙閹烘鍊堕柛顐犲劜閸婄敻鏌ｉ悢鍝勵暭闁哥喓鍋熺槐鎺旀嫚閹绘帗娈绘繝纰夌磿閺佽鐣烽悢纰辨晬婵﹢纭搁崯瀣⒑鐠囨煡鍙勬繛浣冲洤绠烘繝濠傜墛閸嬧晛鈹戦崒姘暈闁抽攱鍨归惀顏堫敇閻愭潙顎涘┑鐐插悑閸旀牜鎹㈠☉銏″殤妞ゆ巻鍋撻柡瀣閵囧嫰顢曢姀銏㈩唺缂備浇椴哥敮鎺曠亽闂佸吋绁撮弲婊堝吹瀹€鍕拻濞撴埃鍋撻柍褜鍓涢崑娑㈡嚐椤栨稒娅犳い鏃囧亹閺嗗棝鏌ㄥ┑鍡欏闁告柨鐏氶妵鍕晜閻ｅ苯寮ㄩ梺璇″櫙缁绘繃淇婇懜闈涚窞閻庯綆鍓欑敮楣冩⒒娴ｇǹ顥忛柛瀣噽閹广垽宕橀鑲╋紱濡炪倕绻愰幊鎰不閸撗€鍋撻悷鏉款棌闁哥姵娲滈懞杈ㄧ節濮橆剛鐣鹃梺缁樻煥閸氬鍩涢幋锔藉€甸柛锔诲幖鏍￠梺闈涙閸熸挳寮婚妶澶婄闁肩⒈鍓欓悡鐔兼倵鐟欏嫭绀冪紒璇茬墦瀵偊宕橀鑲╁姦濡炪倖甯掔€氀囧焵椤掍焦顥堢€规洘锕㈤、娆撳床婢诡垰娲﹂悡鏇㈡煃閳轰礁鏋ゆ繛鍫燂耿閺岋綁鎮㈢粙鍨潚濠殿喖锕ュ浠嬪箖閳╁啯鍎熼柍鈺佸暞閻︼綁姊绘担铏瑰笡闁绘娲熸俊鍓佺矙鐠恒劍娈鹃梺缁樺灦宀ｈ法寮ч埀顒勬⒑閹肩偛鍔€闁告劑鍔庨妶顕€姊婚崒娆戠獢婵炰匠鍕垫闊洦娲橀～鏇㈡煛閸ャ儱鐏╅柛灞诲妽閵囧嫯绠涢幘璺侯杸闂佹娊鏀遍崹鍧楀蓟閻斿吋鍤冮柍杞版缁爼姊洪崨濠冣拹妞ゃ劌锕濠氭晸閻樻彃绐涘銈嗘閺侇喗鎱ㄩ崶鈺冪＝濞达絿枪閳ь剙婀遍弫顕€鎮㈡俊鎾虫川閳ь剟娼ч幗婊呭婵傜ǹ绾ч柛顐ｇ☉婵¤偐绱掑Δ浣侯暡缂佺粯鐩幃鈩冩償閿濆浂鍟嬮梻浣虹《閺備線宕滃┑瀣闁告稑鐡ㄩ悡銉╂倵閿濆懐浠涚紓宥嗩殜濮婂宕掑顑藉亾瀹勬噴褰掑炊瑜滃ù鏍煏婵炵偓娅嗛柛濠傛健閺屻劑寮撮悙娴嬪亾閸濄儳涓嶉柡灞诲劜閻撴洟鏌曟径妯烘灈濠⒀屽櫍閺岋紕鈧絺鏅濈粣鏃堟煛瀹€鈧崰鏍х暦濠婂棭妲鹃柣銏╁灡閻╊垶寮婚敓鐘插窛妞ゆ棁妫勯埀顒佸姍閺岋紕浠︾拠鎻掝潎闂佽鍠撻崐婵嗙暦閹烘垟妲堟慨妤€妫旂槐锟�闂傚倸鍊搁崐鎼佸磹閹间礁纾归柟闂寸绾惧綊鏌熼梻瀵割槮缁炬儳缍婇弻鐔兼⒒鐎靛壊妲紒鎯у⒔閹虫捇鈥旈崘顏佸亾閿濆簼绨绘い鎺嬪灪閵囧嫰骞囬姣挎捇鏌熸笟鍨妞ゎ偅绮撳畷鍗炍旈埀顒勭嵁婵犲嫮纾介柛灞捐壘閳ь剛鎳撻～婵嬪Ω閳轰胶鐤呯紓浣割儐椤戞瑩宕ョ€ｎ喗鐓曟い鎰靛亝缁舵氨绱撻崘鈺傜婵﹤顭峰畷鎺戔枎閹搭厽袦婵犵數濮崑鎾绘⒑椤掆偓缁夌敻骞嗛悙鍝勭婵烇綆鍓欐俊鑲╃磼閹邦収娈滈柡灞糕偓鎰佸悑閹肩补鈧尙鏁栧┑鐐村灦閹稿摜绮旈悽绋课﹂柛鏇ㄥ灠閸愨偓濡炪倖鍔﹀鈧繛宀婁邯濮婅櫣绱掑Ο璇茶敿闂佺ǹ娴烽弫璇差嚕婵犳碍鏅插璺猴工瀹撳棝姊虹紒妯哄缂佷焦鎸冲畷鎴﹀箻鐠囧弶宓嶅銈嗘尰缁嬫垶绂嶉悙顒佸弿婵☆垳鍘ф禍楣冩倵濮樼偓瀚� 闂傚倸鍊搁崐鎼佸磹閹间礁纾归柟闂寸绾惧綊鏌熼梻瀵割槮缁炬儳缍婇弻鐔兼⒒鐎靛壊妲紒鐐劤缂嶅﹪寮婚敐澶婄闁挎繂鎲涢幘缁樼厱闁靛牆鎳庨顓㈡煛鐏炶鈧繂鐣烽锕€唯闁挎棁濮ら惁搴♀攽閻愬樊鍤熷┑顕€娼ч～婵嬪Ω瑜庨～鏇㈡煙閹规劦鍤欑痪鎯у悑缁绘盯宕卞Ο铏圭懆闂佸憡锕槐鏇犳閹惧鐟归柛銉戝嫮褰梻浣规偠閸斿矂鎮ラ崗闂寸箚闁圭虎鍠栫粈鍐┿亜閺冨倸甯剁紒鎰洴濮婃椽宕崟鍨ч梺鎼炲妼缂嶅﹤鐣烽姀鐘嗘椽顢旈崨顓涘亾閸偒娈介柣鎰皺娴犮垽鏌涢弮鈧喊宥夊Φ閸曨垱鏅滈悹鍥皺娴犳悂鎮楃憴鍕┛缂佺粯绻堥悰顔芥償閵婏箑娈熼梺闈涳紡閸愩劌顩梻鍌氬€搁オ鎾磻閸曨個娲晝閳ь剛鍙呴梺鍝勭Р閸斿孩鏅堕敓鐘斥拻闁稿本鐟︾粊鐗堛亜閺囧棗鎳夐崑鎾诲垂椤愩垺璇為悗瑙勬礃缁捇骞冮姀锛勯檮濠㈣泛顑囩粙渚€姊绘担鐟板姢缂佺粯鍔曢敃銏℃綇閳轰緡妫滈梺绋跨箻濡法鎹㈤崱妯镐簻闁哄秲鍔庨。鏌ユ煙椤栨氨澧涢柕鍥у椤㈡洟濮€閳惰￥鍨洪妵鍕敂閸曨偅娈绘繝纰樷偓宕囧煟鐎规洖宕灃闁逞屽墴閿濈偞鎯旈妸锔规嫼闂佸憡绋戦オ鎾倿婵傚憡鐓曢柕澶嬪灥閹冲骸顕ｉ妸銉㈡斀闁绘﹩鍠栭悘杈ㄧ箾婢跺顬奸柣褍鐭傚铏圭磼濡崵鍙嗛梺鍛婅壘椤戝骞冮敓鐘参ㄩ柍鍝勫€搁埀顒傛暬閺屻劌鈹戦崱娑扁偓妤呮煕濡粯灏﹂柡灞剧〒閳ь剨缍嗛崑鍛焊閹殿喚纾肩紓浣贯缚缁犳挻銇勯锝囩疄妞ゃ垺锚閳藉鈻庤箛锝勭椽闂傚倷娴囧畷鐢稿窗閹邦喖鍨濋幖娣灪濞呯姵淇婇妶鍛殲闁哄棙绮撻弻鐔兼倻濡鏆楀銈傛櫆瑜板啴婀侀梺缁樻尭濞寸兘骞楅悩缁樼厽闁规儳鐡ㄧ粈瀣煛瀹€鈧崰鏍嵁閸℃凹妾ㄩ梺鎼炲€楅崰鏍蓟瀹ュ瀵犲鑸瞪戦埢鍫ユ⒑閸濆嫯瀚扮紒澶婂濡叉劙骞掗幊宕囧枛閹筹繝濡堕崨顓熻緢婵犵绱曢崑鎴﹀磹閵堝纾婚柛娑卞灡瀹曟煡鏌涢鐘插姎缂佺姷濮电换婵囩節閸屾稑娅ｉ梺鍝勵儏閻楀﹥绌辨繝鍥舵晬婵犲灚鍔曞▓顓烆渻閵堝懐绠扮紓宥咃工椤繑绻濆顒傦紲濠电偛妫欓崺鍫澪ｉ鈧铏规兜閸滀礁娈濈紓浣介哺濞叉粓宕氶幒鎴旀瀻闁规儳纾娲⒑閹稿孩鐓ラ柟纰卞亝缁傚秵绺介崨濞炬嫼闂佸憡绻傜€氬嘲危瑜版帗鐓曢柕濞у啯鐏堥悗娈垮枟閹倸顕ｉ鈧畷濂告偄閸濆嫬绠伴梻鍌欑閹诧繝宕濊瀵板﹪鎳為妷褜娲搁梺鍛婃寙閸涱垽绱冲┑鐐舵彧缂嶁偓婵炲拑绲块弫顔尖槈濮樿京锛滈柣搴秵閸嬪懐浜搁幍顔剧＜闁稿本绋戝ù顕€鏌℃担绋挎殻鐎规洘甯掗～婵嬪箟鐎ｎ剙绨ユ繝鐢靛У椤旀牠宕板Δ鍛櫇闁冲搫鎳庣粈鍫ユ煥閺囩偛鈧綊宕愰悽鍛婄厵闁诡垱婢樿闂佹娊鏀辩敮鎺楁箒闂佹寧绻傞幊蹇涘箟閹间焦鐓ユ繛鎴炨缚鑲栫紓浣介哺鐢繝銆佸璺哄窛妞ゆ挾濮冲鎾翠繆閵堝洤啸闁稿鍋ゅ畷褰掑垂椤旂偓娈鹃梺鍓插亝濞诧箓寮崱娑欑厱閻忕偟鍋撻惃鎴︽煏閸剛鐣垫慨濠呮閹风娀骞撻幒鎴炵槪缂傚倸鍊哥粔鏉懳涘▎鎴犵焿鐎广儱顦崘鈧銈嗘尵閸嬬喖宕Δ浣虹閻庣數枪瀛濆銈嗗灥濡繈骞冮垾鏂ユ瀻闁瑰墽琛ラ幏鍝勵渻閵堝棙灏柛鏂块叄閹箖宕￠悜鍡欏數閻熸粍绮撳畷褰掓焼瀹ュ憘锕傛煕閺囥劌鐏犳俊顐ｏ耿閺屾盯鈥﹂幋婵囩亐闂佺ǹ顑嗛幐楣冨箟閹绢喖绀嬫い鎾寸⊕閺侀潧鈹戦悩鍨毄濠殿喗娼欑叅闁挎洖鍊哥壕褰掓⒑閸噮鍎嶅ù婊勭矒閻擃偊宕堕妸锕€纰嶅銈呯箞閸婃繈寮诲☉姘ｅ亾閿濆骸浜濈€规洖鐬奸埀顒侇問閸犳牠鍩€椤掑倸娅忔俊淇卞妼閳规垿鎮欓幓鎺撳€梺缁橆殕濞茬喖宕洪悙鍝勭闁挎棁妫勬禍褰掓煟鎼粹剝璐″┑顔芥尦钘熸繝闈涱儐閳锋垹绱掔€ｎ厼鍔垫い顐畵閺屾盯寮崸妤€寮板Δ鐘靛仜椤︻垶锝為姀鐘垫殕闁逞屽墴閹潡鍩€椤掆偓閳规垿鎮欓弶鎴犱桓鐎光偓閿濆懏鍋ラ柟顔兼健瀹曘劎鈧稒菤閹锋椽姊洪棃鈺佺槣闁告瑢鍋撳┑锛勫亾閹倿寮诲☉銏″亹闁归鐒﹂悿渚€鎮楀▓鍨灍闁绘搫绻濋悰顕€寮介妸锕€顎撻梺闈╁瘜閸樼厧顕ｉ幎鑺モ拻濞达綀娅ｇ敮娑欑箾閸欏澧电€规洘鍔欏畷鐑筋敇濞戞ü澹曞┑顔结缚閸嬫挾鈧熬鎷�
核心提示：假如你正在开发一个具有多媒体功能的通讯录程序，这个通讯录除了能存储通常的文字信息如姓名、地址、电话号码外，More Effective C++：防止资源泄漏，还能存储照片和声音(可以给出他们名字的正确发音)，为了实现这个通信录，但是auto_ptr(或者类似于auto_ptr的类)能化繁为简，它不仅把令人不好理解的代码
假如你正在开发一个具有多媒体功能的通讯录程序。这个通讯录除了能存储通常的文字信息如姓名、地址、电话号码外，还能存储照片和声音(可以给出他们名字的正确发音)。
为了实现这个通信录，你可以这样设计:
class Image { // 用于图像数据
public:
Image(const string& imageDataFileName);
...
};
class AudioClip { // 用于声音数据
public:
AudioClip(const string& audioDataFileName);
...
};
class PhoneNumber { ... }; // 用于存储电话号码
class BookEntry { // 通讯录中的条目
public:
BookEntry(const string& name,
const string& address = "",
const string& imageFileName = "",
const string& audioClipFileName = "");
~BookEntry();
// 通过这个函数加入电话号码
void addPhoneNumber(const PhoneNumber& number);
...
PRivate:
string theName; // 人的姓名
string theAddress; // 他们的地址
list thePhones; // 他的电话号码
Image *theImage; // 他们的图像
AudioClip *theAudioClip; // 他们的一段声音片段
};
通讯录的每个条目都有姓名数据，所以你需要带有参数的构造函数(参见条款3)，不过其它内容(地址、图像和声音的文件名)都是可选的。注重应该使用链表类(list)存储电话号码，这个类是标准C++类库(STL)中的一个容器类(container classes)。(参见Effective C++条款49 和本书条款35)
编写BookEntry 构造函数和析构函数，有一个简单的方法是:
BookEntry::BookEntry(const string& name,const string& address,
const string& imageFileName,
Const string& audioClipFileName)
: theName(name), theAddress(address),
theImage(0), theAudioClip(0)
{
if (imageFileName != "") {
theImage = new Image(imageFileName);
}
if (audioClipFileName != "") {
theAudioClip = new AudioClip(audioClipFileName);
}
}
BookEntry::~BookEntry()
{
delete theImage;
delete theAudioClip;
}
构造函数把指针theImage和theAudioClip初始化为空，然后假如其对应的构造函数参数不是空，就让这些指针指向真实的对象。析构函数负责删除这些指针，确保BookEntry对象不会发生资源泄漏。因为C++确保删除空指针是安全的，所以BookEntry的析构函数在删除指针前不需要检测这些指针是否指向了某些对象。
看上去似乎一切良好，在正常情况下确实不错，但是在非正常情况下(例如在有异常发生的情况下)它们恐怕就不会良好了。
请想一下假如BookEntry的构造函数正在执行中，一个异常被抛出，会发生什么情况呢?:
if (audioClipFileName != "") {
theAudioClip = new AudioClip(audioClipFileName);
}
一个异常被抛出，可以是因为Operator new(参见条款8)不能给AudioClip分配足够的内存，也可以因为AudioClip的构造函数自己抛出一个异常。不论什么原因，假如在BookEntry构造函数内抛出异常，这个异常将传递到建立BookEntry对象的地方(在构造函数体的外面。 译者注)。
现在假设建立theAudioClip对象建立时，一个异常被抛出(而且传递程序控制权到BookEntry构造函数的外面)，那么谁来负责删除theImage已经指向的对象呢?答案显然应该是由BookEntry来做，但是这个想当然的答案是错的。BookEntry根本不会被调用，永远不会。
C++仅仅能删除被完全构造的对象(fully contrUCted objects), 只有一个对象的构造函数完全运行完毕，这个对象才能被完全地构造。所以假如一个BookEntry对象b做为局部对象建立，如下:
void testBookEntryClass()
{
BookEntry b("Addison-Wesley Publishing Company","One Jacob Way, Reading, MA 01867");
...
}
并且在构造b的过程中，一个异常被抛出，b的析构函数不会被调用。而且假如你试图采取主动手段处理异常情况，即当异常发生时调用delete，如下所示:
void testBookEntryClass()
{
BookEntry *pb = 0;
try {
pb = new BookEntry("Addison-Wesley Publishing Company","One Jacob Way, Reading, MA 01867");
...
}
catch (...) { // 捕捉所有异常
delete pb; // 删除pb,当抛出异常时
throw; // 传递异常给调用者
}
delete pb; // 正常删除pb
}
你会发现在BookEntry构造函数里为Image分配的内存仍然被丢失了，这是因为假如new操作没有成功完成，程序不会对pb进行赋值操作。假如BookEntry的构造函数抛出一个异常，pb将是一个空值，所以在catch块中删除它除了让你自己感觉良好以外没有任何作用。用灵巧指针(smart pointer)类auto_ptr
C++拒绝为没有完成构造操作的对象调用析构函数是有一些原因的，而不是故意为你制造困难。原因是:在很多情况下这么做是没有意义的，甚至是有害的。假如为没有完成构造操作的对象调用析构函数，析构函数如何去做呢?仅有的办法是在每个对象里加入一些字节来指示构造函数执行了多少步?然后让析构函数检测这些字节并判定该执行哪些操作。这样的记录会减慢析构函数的运行速度，并使得对象的尺寸变大。C++避免了这种开销，但是代价是不能自动地删除被部分构造的对象。(类似这种在程序行为与效率这间进行折衷处理的例子还可以参见Effective C++条款13)
因为当对象在构造中抛出异常后C++不负责清除对象，所以你必须重新设计你的构造函数以让它们自己清除。经常用的方法是捕捉所有的异常，然后执行一些清除代码，最后再重新抛出异常让它继续转递。如下所示，在BookEntry构造函数中使用这个方法:
BookEntry::BookEntry(const string& name,
const string& address,
const string& imageFileName,
const string& audioClipFileName)
: theName(name), theAddress(address),
theImage(0), theAudioClip(0)
{
try { // 这try block是新加入的
if (imageFileName != "") {
theImage = new Image(imageFileName);
}
if (audioClipFileName != "") {
theAudioClip = new AudioClip(audioClipFileName);
}
}
catch (...) { // 捕捉所有异常
delete theImage; // 完成必要的清除代码
delete theAudioClip;
throw; // 继续传递异常
}
}
不用为BookEntry中的非指针数据成员操心，在类的构造函数被调用之前数据成员就被自动地初始化。所以假如BookEntry构造函数体开始执行，对象的theName, theAddress 和 thePhones数据成员已经被完全构造好了。这些数据可以被看做是完全构造的对象，所以它们将被自动释放，不用你介入操作。当然假如这些对象的构造函数调用可能会抛出异常的函数，那么哪些构造函数必须去考虑捕捉异常，在答应它们继续传递之前完成必需的清除操作。
你可能已经注重到BookEntry构造函数的catch块中的语句与在BookEntry的析构函数的语句几乎一样。这里的代码重复是绝对不可容忍的，所以最好的方法是把通用代码移入一个私有helper function中，让构造函数与析构函数都调用它。
class BookEntry {
public:
... // 同上
private:
...
void cleanup(); // 通用清除代码
};
void BookEntry::cleanup()
{
delete theImage;
delete theAudioClip;
}
BookEntry::BookEntry(const string& name,const string& address,
const string& imageFileName,
const string& audioClipFileName)
: theName(name), theAddress(address),
theImage(0), theAudioClip(0)
{
try {
... // 同上
}
catch (...) {
cleanup(); // 释放资源
throw; // 传递异常
}
}
BookEntry::~BookEntry()
{
cleanup();
}
这就行了，但是它没有考虑到下面这种情况。假设我们略微改动一下设计，让theImage 和theAudioClip是常量(constant)指针类型:
class BookEntry {
public:
... // 同上
private:
...
Image * const theImage; // 指针现在是
AudioClip * const theAudioClip; // const类型
};
必须通过BookEntry构造函数的成员初始化表来初始化这样的指针，因为再也没有其它地方可以给const指针赋值。通常会这样初始化theImage和theAudioClip:
// 一个可能在异常抛出时导致资源泄漏的实现方法
BookEntry::BookEntry(const string& name,const string& address,const string& imageFileName,
const string& audioClipFileName)
: theName(name), theAddress(address),
theImage(imageFileName != ""
? new Image(imageFileName)
: 0),
theAudioClip(audioClipFileName != ""
? new AudioClip(audioClipFileName)
: 0)
{}
这样做导致我们原先一直想避免的问题重新出现:假如theAudioClip初始化时一个异常被抛出，theImage所指的对象不会被释放。而且我们不能通过在构造函数中增加try和catch 语句来解决问题，因为try和catch是语句，而成员初始化表仅答应有表达式(这就是为什么我们必须在 theImage 和 theAudioClip的初始化中使用?:以代替if-then-else的原因)。
无论如何，在异常传递之前完成清除工作的唯一的方法就是捕捉这些异常，所以假如我们不能在成员初始化表中放入try和catch语句，我们把它们移到其它地方。一种可能是在私有成员函数中，用这些函数返回指针，指向初始化过的theImage 和 theAudioClip对象。
class BookEntry {
public:
... // 同上
private:
... // 数据成员同上
Image * initImage(const string& imageFileName);
AudioClip * initAudioClip(const string&
audioClipFileName);
};
BookEntry::BookEntry(const string& name,const string& address,const string& imageFileName,
const string& audioClipFileName): theName(name), theAddress(address),
theImage(initImage(imageFileName)),
theAudioClip(initAudioClip(audioClipFileName)){}
// theImage 被首先初始化,所以即使这个初始化失败也
// 不用担心资源泄漏，这个函数不用进行异常处理。
Image * BookEntry::initImage(const string& imageFileName)
{
if (imageFileName != "") return new Image(imageFileName);
else return 0;
}
// theAudioClip被第二个初始化, 所以假如在theAudioClip
// 初始化过程中抛出异常，它必须确保theImage的资源被释放。
// 因此这个函数使用try...catch 。
AudioClip * BookEntry::initAudioClip(const string& audioClipFileName)
{
try {
if (audioClipFileName != "") {
return new AudioClip(audioClipFileName);
}
else return 0;
}
catch (...) {
delete theImage;
throw;
}
}
上面的程序的确不错，也解决了令我们头疼不已的问题。不过也有缺点，在原则上应该属于构造函数的代码却分散在几个函数里，这令我们很难维护。
更好的解决方法是采用条款9的建议，把theImage 和 theAudioClip指向的对象做为一个资源，被一些局部对象治理。这个解决方法建立在这样一个事实基础上:theImage 和theAudioClip是两个指针，指向动态分配的对象，因此当指针消失的时候，这些对象应该被删除。auto_ptr类就是基于这个目的而设计的。(参见条款9)因此我们把theImage 和 theAudioClip raw指针类型改成对应的auto_ptr类型。
class BookEntry {
public:
... // 同上
private:
...
const auto_ptr theImage; // 它们现在是
const auto_ptr theAudioClip; // auto_ptr对象
};
这样做使得BookEntry的构造函数即使在存在异常的情况下也能做到不泄漏资源，而且让我们能够使用成员初始化表来初始化theImage 和 theAudioClip，如下所示:
BookEntry::BookEntry(const string& name,const string& address,const string& imageFileName,const string& audioClipFileName): theName(name), theAddress(address),theImage(imageFileName != ""? new Image(imageFileName)
: 0),theAudioClip(audioClipFileName != ""? new AudioClip(audioClipFileName): 0){}
在这里，假如在初始化theAudioClip时抛出异常，theImage已经是一个被完全构造的对象，所以它能被自动删除掉，就象theName, theAddress和thePhones一样。而且因为theImage 和 theAudioClip现在是包含在BookEntry中的对象，当BookEntry被删除时它们能被自动地删除。因此不需要手工删除它们所指向的对象。可以这样简化BookEntry的析构函数:
BookEntry::~BookEntry()
{} // nothing to do!
这表示你能完全去掉BookEntry的析构函数。
综上所述，假如你用对应的auto_ptr对象替代指针成员变量，就可以防止构造函数在存在异常时发生资源泄漏，你也不用手工在析构函数中释放资源，并且你还能象以前使用非const指针一样使用const指针，给其赋值。
在对象构造中，处理各种抛出异常的可能，是一个棘手的问题，但是auto_ptr(或者类似于auto_ptr的类)能化繁为简。它不仅把令人不好理解的代码隐藏起来，而且使得程序在面对异常的情况下也能保持正常运行。
中查找“More Effective C++：防止资源泄漏”更多相关内容
中查找“More Effective C++：防止资源泄漏”更多相关内容更多精彩
赞助商链接
