瘦身前后——兼谈C++语言进化
2008-03-08 21:41:12 来源：WEB开发网 闂傚倸鍊搁崐鎼佸磹閹间礁纾归柟闂寸绾惧綊鏌熼梻瀵割槮缁炬儳缍婇弻鐔兼⒒鐎靛壊妲紒鎯у⒔閹虫捇鈥旈崘顏佸亾閿濆簼绨绘い鎺嬪灪閵囧嫰骞囬姣挎捇鏌熸笟鍨妞ゎ偅绮撳畷鍗炍旈埀顒勭嵁婵犲嫮纾介柛灞捐壘閳ь剛鎳撻～婵嬪Ω閳轰胶鐤呯紓浣割儐椤戞瑩宕ョ€ｎ喗鐓曟い鎰靛亝缁舵氨绱撻崘鈺傜婵﹤顭峰畷鎺戔枎閹搭厽袦婵犵數濮崑鎾绘⒑椤掆偓缁夌敻骞嗛悙鍝勭婵烇綆鍓欐俊鑲╃磼閹邦収娈滈柡灞糕偓鎰佸悑閹肩补鈧尙鏁栧┑鐐村灦閹稿摜绮旈悽绋课﹂柛鏇ㄥ灠閸愨偓濡炪倖鍔﹀鈧繛宀婁邯濮婅櫣绱掑Ο璇茶敿闂佺ǹ娴烽弫璇差嚕婵犳碍鏅插璺猴工瀹撳棝姊虹紒妯哄缂佷焦鎸冲畷鎴﹀箻鐠囧弶宓嶅銈嗘尰缁嬫垶绂嶉悙顒佸弿婵☆垳鍘ф禍楣冩倵濮樼偓瀚�
闂傚倸鍊搁崐鎼佸磹閹间礁纾归柟闂寸绾惧綊鏌熼梻瀵割槮缁炬儳缍婇弻鐔兼⒒鐎靛壊妲紒鎯у⒔閹虫捇鈥旈崘顏佸亾閿濆簼绨奸柟鐧哥秮閺岋綁顢橀悙鎼闂侀潧妫欑敮鎺楋綖濠靛鏅查柛娑卞墮椤ユ艾鈹戞幊閸婃鎱ㄩ悜钘夌；婵炴垟鎳為崶顒佸仺缂佸瀵ч悗顒勬⒑閻熸澘鈷旂紒顕呭灦瀹曟垿骞囬悧鍫㈠幍缂傚倷鐒﹂敋缂佹う鍥ㄧ厓鐟滄粓宕滈敃鍌氱煑闁告劦鐓堝ḿ鏍煕濠靛棗鐝旂憸鏂跨暦閹偊妲炬繛瀵稿Т閵堢ǹ顫忛搹瑙勫珰闁肩⒈鍓涢澶愭⒑閻撳海绉虹紒鐘崇墵楠炲啯銈ｉ崘鈺佲偓濠氭煢濡警妲奸柟鑺ユ礋濮婃椽妫冨☉杈€嗘繝纰樷偓铏枠鐎规洏鍨介幃浠嬪川婵炵偓瀚奸梺鑽ゅ枑閻熴儳鈧氨鍏樺畷顖濈疀濞戞瑧鍘遍梺缁樏壕顓熸櫠閻㈠憡鐓忛柛鈩冾殔閳ь剙婀辩紓鎾寸鐎ｎ亜绐涙繝鐢靛Т鐎氼剟鐛崼銉︹拺缁绢厼鎳庨ˉ宥夋煙濞茶绨芥俊鍙夊姍瀵挳鎮㈤崫鍕ㄥ彏闂傚倸鍊搁崐椋庢濮橆兗缂氱憸宥囧弲闂侀潧鐗嗗ú鐘诲磻閹炬剚娼╂い鎰╁灩缁侇噣姊虹紒妯圭繁闁革綇缍侀悰顕€骞掗幊铏閸┾偓妞ゆ帒鍊绘稉宥夋煥濠靛棙顥犵紒鈾€鍋撻梻鍌氬€搁悧濠勭矙閹达箑姹叉繛鍡楃贩閻熸壋鍫柛顐犲灮閺嗩偊姊洪崫鍕効缂傚秳鐒﹂幈銊╁焵椤掑嫭鐓冮柟顖滃绾偓绻濋埀顒佹綇閵娧呭骄闂佸搫娲ㄩ崰鎾跺姬閳ь剙鈹戦鏂や緵闁告﹢绠栧畷銏ゆ偨閸涘ň鎷虹紓鍌欑劍閿氬┑顕嗙畵閺屾盯骞橀弶鎴濇懙闂佽鍠楄摫婵炵厧绻樻俊鎼佸Χ閸モ晝鏆伴梻鍌欑濠€杈╁垝椤栨粍鏆滈柣鎰摠濞呯姵绻涢幋鐐寸殤缁炬崘鍋愮槐鎾存媴鐠愵垳绱板┑鐐村絻椤曨參鍩€椤掑喚娼愭繛鍙夌墪閻ｇ兘顢楅崘顏冪胺闂傚倷绀侀幉锟犲礉閺囥垹鐤柣妯款嚙缁€鍫熺節闂堟稓澧涚€规洖寮剁换娑㈠箣閻愩劎绱伴梺鍝勬濡鍩為幋锔藉亹閺夊牜鍋勯崢锟犳⒑鏉炴壆鍔嶉柣妤佺矌濡叉劙骞樼€涙ê顎撴繛瀵稿Т椤戝懘骞楅悽鍛娾拺闁革富鍘介崵鈧┑鐐茬湴閸婃繈骞冩ィ鍐╁€婚柦妯侯槺椤斿﹪姊虹憴鍕剹闁告ü绮欏畷鎾绘偨閸涘ň鎷洪梺鑽ゅ枑濠㈡﹢骞冩笟鈧弻锝夊箳閻愮數鏆ら梺璇″枟椤ㄥ﹪鐛弽銊﹀闁稿繐顦扮€氳棄鈹戦悙鑸靛涧缂佹彃娼″畷鏇㈠Χ婢跺﹤鎯為梺閫炲苯澧存慨濠冩そ楠炴牠鎮欏ù瀣壕闁哄稁鍘介崑瀣煟濡灝鍚圭€规挷绶氶悡顐﹀炊閵娧€濮囬梺鍝勬噺閹倿寮婚妸鈺傚亞闁稿本绋戦锟�
濠电姷鏁告慨鐑藉极閸涘﹥鍙忛柣鎴ｆ閺嬩線鏌涘☉姗堟敾闁告瑥绻橀弻锝夊箣閿濆棭妫勯梺鍝勵儎缁舵岸寮诲☉妯锋婵鐗婇弫楣冩⒑閸涘﹦鎳冪紒缁樺灴婵＄敻宕熼姘鳖啋闂佸憡顨堥崑鐔哥閼测晝纾藉ù锝呮惈椤庡矂鏌涢妸銉у煟鐎殿喛顕ч埥澶愬閻樼數鏉搁梻鍌氬€搁悧濠勭矙閹烘鍊堕柛顐犲劜閸婄敻鏌ｉ悢鍝勵暭闁哥喓鍋熺槐鎺旀嫚閹绘帗娈绘繝纰夌磿閺佽鐣烽悢纰辨晬婵﹢纭搁崯瀣⒑鐠囨煡鍙勬繛浣冲洤绠烘繝濠傜墛閸嬧晛鈹戦崒姘暈闁抽攱鍨归惀顏堫敇閻愭潙顎涘┑鐐插悑閸旀牜鎹㈠☉銏″殤妞ゆ巻鍋撻柡瀣閵囧嫰顢曢姀銏㈩唺缂備浇椴哥敮鎺曠亽闂佸吋绁撮弲婊堝吹瀹€鍕拻濞撴埃鍋撻柍褜鍓涢崑娑㈡嚐椤栨稒娅犳い鏃囧亹閺嗗棝鏌ㄥ┑鍡欏闁告柨鐏氶妵鍕晜閻ｅ苯寮ㄩ梺璇″櫙缁绘繃淇婇懜闈涚窞閻庯綆鍓欑敮楣冩⒒娴ｇǹ顥忛柛瀣噽閹广垽宕橀鑲╋紱濡炪倕绻愰幊鎰不閸撗€鍋撻悷鏉款棌闁哥姵娲滈懞杈ㄧ節濮橆剛鐣鹃梺缁樻煥閸氬鍩涢幋锔藉€甸柛锔诲幖鏍￠梺闈涙閸熸挳寮婚妶澶婄闁肩⒈鍓欓悡鐔兼倵鐟欏嫭绀冪紒璇茬墦瀵偊宕橀鑲╁姦濡炪倖甯掔€氀囧焵椤掍焦顥堢€规洘锕㈤、娆撳床婢诡垰娲﹂悡鏇㈡煃閳轰礁鏋ゆ繛鍫燂耿閺岋綁鎮㈢粙鍨潚濠殿喖锕ュ浠嬪箖閳╁啯鍎熼柍鈺佸暞閻︼綁姊绘担铏瑰笡闁绘娲熸俊鍓佺矙鐠恒劍娈鹃梺缁樺灦宀ｈ法寮ч埀顒勬⒑閹肩偛鍔€闁告劑鍔庨妶顕€姊婚崒娆戠獢婵炰匠鍕垫闊洦娲橀～鏇㈡煛閸ャ儱鐏╅柛灞诲妽閵囧嫯绠涢幘璺侯杸闂佹娊鏀遍崹鍧楀蓟閻斿吋鍤冮柍杞版缁爼姊洪崨濠冣拹妞ゃ劌锕濠氭晸閻樻彃绐涘銈嗘閺侇喗鎱ㄩ崶鈺冪＝濞达絿枪閳ь剙婀遍弫顕€鎮㈡俊鎾虫川閳ь剟娼ч幗婊呭婵傜ǹ绾ч柛顐ｇ☉婵¤偐绱掑Δ浣侯暡缂佺粯鐩幃鈩冩償閿濆浂鍟嬮梻浣虹《閺備線宕滃┑瀣闁告稑鐡ㄩ悡銉╂倵閿濆懐浠涚紓宥嗩殜濮婂宕掑顑藉亾瀹勬噴褰掑炊瑜滃ù鏍煏婵炵偓娅嗛柛濠傛健閺屻劑寮撮悙娴嬪亾閸濄儳涓嶉柡灞诲劜閻撴洟鏌曟径妯烘灈濠⒀屽櫍閺岋紕鈧絺鏅濈粣鏃堟煛瀹€鈧崰鏍х暦濠婂棭妲鹃柣銏╁灡閻╊垶寮婚敓鐘插窛妞ゆ棁妫勯埀顒佸姍閺岋紕浠︾拠鎻掝潎闂佽鍠撻崐婵嗙暦閹烘垟妲堟慨妤€妫旂槐锟�闂傚倸鍊搁崐鎼佸磹閹间礁纾归柟闂寸绾惧綊鏌熼梻瀵割槮缁炬儳缍婇弻鐔兼⒒鐎靛壊妲紒鎯у⒔閹虫捇鈥旈崘顏佸亾閿濆簼绨绘い鎺嬪灪閵囧嫰骞囬姣挎捇鏌熸笟鍨妞ゎ偅绮撳畷鍗炍旈埀顒勭嵁婵犲嫮纾介柛灞捐壘閳ь剛鎳撻～婵嬪Ω閳轰胶鐤呯紓浣割儐椤戞瑩宕ョ€ｎ喗鐓曟い鎰靛亝缁舵氨绱撻崘鈺傜婵﹤顭峰畷鎺戔枎閹搭厽袦婵犵數濮崑鎾绘⒑椤掆偓缁夌敻骞嗛悙鍝勭婵烇綆鍓欐俊鑲╃磼閹邦収娈滈柡灞糕偓鎰佸悑閹肩补鈧尙鏁栧┑鐐村灦閹稿摜绮旈悽绋课﹂柛鏇ㄥ灠閸愨偓濡炪倖鍔﹀鈧繛宀婁邯濮婅櫣绱掑Ο璇茶敿闂佺ǹ娴烽弫璇差嚕婵犳碍鏅插璺猴工瀹撳棝姊虹紒妯哄缂佷焦鎸冲畷鎴﹀箻鐠囧弶宓嶅銈嗘尰缁嬫垶绂嶉悙顒佸弿婵☆垳鍘ф禍楣冩倵濮樼偓瀚� 闂傚倸鍊搁崐鎼佸磹閹间礁纾归柟闂寸绾惧綊鏌熼梻瀵割槮缁炬儳缍婇弻鐔兼⒒鐎靛壊妲紒鐐劤缂嶅﹪寮婚敐澶婄闁挎繂鎲涢幘缁樼厱闁靛牆鎳庨顓㈡煛鐏炶鈧繂鐣烽锕€唯闁挎棁濮ら惁搴♀攽閻愬樊鍤熷┑顕€娼ч～婵嬪Ω瑜庨～鏇㈡煙閹规劦鍤欑痪鎯у悑缁绘盯宕卞Ο铏圭懆闂佸憡锕槐鏇犳閹惧鐟归柛銉戝嫮褰梻浣规偠閸斿矂鎮ラ崗闂寸箚闁圭虎鍠栫粈鍐┿亜閺冨倸甯剁紒鎰洴濮婃椽宕崟鍨ч梺鎼炲妼缂嶅﹤鐣烽姀鐘嗘椽顢旈崨顓涘亾閸偒娈介柣鎰皺娴犮垽鏌涢弮鈧喊宥夊Φ閸曨垱鏅滈悹鍥皺娴犳悂鎮楃憴鍕┛缂佺粯绻堥悰顔芥償閵婏箑娈熼梺闈涳紡閸愩劌顩梻鍌氬€搁オ鎾磻閸曨個娲晝閳ь剛鍙呴梺鍝勭Р閸斿孩鏅堕敓鐘斥拻闁稿本鐟︾粊鐗堛亜閺囧棗鎳夐崑鎾诲垂椤愩垺璇為悗瑙勬礃缁捇骞冮姀锛勯檮濠㈣泛顑囩粙渚€姊绘担鐟板姢缂佺粯鍔曢敃銏℃綇閳轰緡妫滈梺绋跨箻濡法鎹㈤崱妯镐簻闁哄秲鍔庨。鏌ユ煙椤栨氨澧涢柕鍥у椤㈡洟濮€閵忋垹濮辨繝娈垮枛閿曘儱顪冮挊澶屾殾闁绘垹鐡旈弫鍥ㄧ箾閹寸偟鎳冮柣婵嬩憾濮婄粯鎷呴崨闈涚秺椤㈡牠宕ㄩ鍥ㄧ☉閳规垹鈧綆浜為悾楣冩⒑闁偛鑻晶顖炴煏閸パ冾伂缂佺姵鐩獮妯尖偓鍨偠閸嬫劖绻濈喊妯活潑闁搞劍澹嗛埀顒佺濠㈡﹢锝炶箛鎾佹椽顢旈崟顏嗙倞闂備礁鎲″ú锕傚礈濮樿泛绠柛妤冨亹閺€浠嬫煟閹邦厼绲荤紒鐙欏啰鏆嗛柨婵嗘噺閸嬨儲顨ラ悙鏉戠伌濠殿喒鍋撻梺缁橈供閸嬪懘寮埀顒€鈹戦悩鍨毄濠殿喖顕埀顒佸嚬閸ｏ絽顕ｉ崼鏇炵濞达絽鍘滈幏娲⒑閸涘﹦绠撻悗姘煎幖椤斿繐鈹戦崱蹇旀杸濡炪倖姊归崕鎶藉储閹绢喗鐓欐い鏃囶嚙瀹撳棗鈹戦敍鍕幋闁糕晪绻濆畷鎺懳旀担鍓蹭紲濠电姷鏁搁崑鐘诲箵椤忓棗绶ゅù鐘差儏缁犺銇勯幇鈺佲偓鏍汲濠婂牊鍋ｉ弶鐐村椤掔喖鏌ｉ弬鎸庮棦闁哄矉缍侀幃銏犵暋閹殿喚娉块梻浣姐€€閸嬫捇鏌ゆ慨鎰偓妤冨婵傚憡鐓曢悘鐐靛亾閻ㄦ垹鈧稒绻傝灃婵°倕锕ｇ花鐑芥煕濡も偓閸熷潡鎮鹃悜鑺ュ亗閹兼惌鍠楅崓鐢告⒑閹稿海绠撻柟鍐茬У缁旂喖寮撮姀鈾€鎷洪梺鍛婄箓鐎氼剟寮冲▎鎾寸厽婵°倐鍋撴俊顐ｇ〒閸掓帡宕奸妷銉ь槰闂佸磭鎳撻妵妯艰姳婵犳碍顥婃い鎰╁灪閹兼劖绻涚€电ǹ鍘撮挊婵嬫煥閺囨浜鹃梻鍥ь槹缁绘繃绻濋崒婊冣叡闂佷紮绲惧浠嬪蓟閿涘嫪娌悹鍥ㄥ絻椤牓姊虹€圭媭娼愰柛銊ョ仢閻ｇ兘宕￠悙鈺傤潔闂佺懓鍚€缁€浣圭閻愵兛绻嗛柕鍫濆€告禍鎯ь渻閵堝骸寮ㄩ柛搴☆煼绡撳〒姘ｅ亾闁哄本鐩幃鈺佺暦閸パ€鎷版繝鐢靛Л閸嬫挸銆掑锝呬壕濠殿喖锕ㄥ▍锝囨閹烘嚦鐔煎即閻旈浼岄梺璇″枤閸忔ɑ淇婇悿顖ｆХ闂佺ǹ顑嗛幐鎼侊綖濠靛鍋傞幖娣灮娴滃墽绱撻崒娆戣窗闁哥姵姘ㄩ崚鎺楊敍閻愬弬褔鏌ㄥ┑鍡╂Ц缂佲偓閸愵喗鐓冮柛婵嗗閺嗘瑦顨ラ悙鑼濞ｅ洤锕幃娆擃敂閸曘劌浜鹃柡宥庡幖缁€澶愭煙鏉堝墽鐣辩痪鎯х秺閺岋繝宕堕妷銉т患闂佸憡鍨规繛鈧鐐寸墪鑿愭い鎺嗗亾濠碘€茬矙閺岋綁骞樼捄鐑樼亪闂佺粯鎼╅崑濠傜暦閹偊妾ㄩ梺绋块缁绘﹢寮诲☉銏犵睄闁逞屽墰閸掓帡骞樼拠鑼舵憰闂佸搫娲㈤崹褰掓倷婵犲嫭鍠愮€广儱顦介弫鍌涖亜閹捐泛袥闁稿鎸搁埢鎾诲垂椤旂晫浜舵繝鐢靛仜閸氬鎮烽妸鈺傚€堕柟鐑橆殕閳锋垿鏌涘☉姗堝姛缂佺姵鎹囬幃妤€顫濋悡搴♀拤濡炪們鍊曢崐鍦崲濠靛牆鏋堝璺虹灱閿涚喖姊虹粙娆惧剱闁搞劌鐏濋悾鐑藉箛閺夎法顓洪梺鎸庢磵閸嬫捇鏌涢妸銉モ偓鍦崲濞戞﹩鍟呮い鏃囧吹閸戝綊姊虹粙娆惧劀缂佺粯绻堝璇差吋婢跺﹣绱堕梺鍛婃处閸撴瑥鈻嶉敐鍥╃＝濞达絽鎼牎闂佺粯顨堟繛鈧€殿喛顕ч鍏煎緞婵犲嫬骞愬┑鐐舵彧缁蹭粙骞夐垾鏂ユ灁闁哄被鍎查埛鎴犵磼鐎ｎ偄顕滈柟鐧哥秮閺屾盯鎮╁畷鍥р拰閻庢鍠栭…宄邦嚕閹绢喖顫呴柣姗€娼ч埀顒傚仱閹嘲饪伴崘顎倝鏌ゆウ鍧楀摵缂佺粯绻傞～婵嬵敇閻樻彃绠ラ梻鍌欑閹诧繝宕归鐐茬９闁哄稁鍋€閸嬫挸顫濋悙顒€顏�
核心提示：前一阵子写了一篇文章，提到语言进化的职责之一，瘦身前后——兼谈C++语言进化，就是去除语言中的tricks（职责之二是去除非本质复杂性），常看我blog的朋友肯定记得我曾写过的boost源码剖析系列，lambda能不能进标准则要看几个提案者的工作，目前还没有Wording出来，本来这个系列是打算成书的，但随着对C++的
前一阵子写了一篇文章，提到语言进化的职责之一，就是去除语言中的tricks（职责之二是去除非本质复杂性）。
常看我blog的朋友肯定记得我曾写过的boost源码剖析系列。本来这个系列是打算成书的，但随着对C++的熟悉发生了一些转变，对语言级技术的热衷逐渐消退，再回过头来看boost库中的一些组件，发现原本觉得很有写的必要的东西顿时消失了。Scott Meyers的主页上也列有一个写Boost Under The Hood的计划，一直也不见成文，兴许也有类似的原因。
一门语言应该是“Make simple things simple, make complex things possible”的。当我们用语言来表达思想的时候，这门语言应该能够提供这样的能力：即让我们能够最直接地表达我们的意思，多一分则太多，少一分则太少，好比古人形容美女：增一分则太肥，减一分则太瘦。
这个问题上，有一个我认为是广泛的误解，就是“KISS便意味着要精简语言，并避免在编码中使用‘高阶’语言特性”。对此有一句话我觉得说得好：你不能通过从一门语言中去掉东西来增加表达力。高阶特性是一面利刃，用得不好固然伤了自己，但这并不表明就没有用。任何东西都是在它真正适用的地方适用，霸王硬上弓的话弓断弦崩反而伤及自身。所以，仅仅因为高阶特性轻易误用（而且高阶特性的确也轻易吸引人去用且轻易误用，不过这是另一个问题），就断然在任何地方都不用并宣称这样才是KISS的话，便因噎废食了。举个例子，高阶函数是有用的，假如在真正需要高阶函数的地方不用高阶函数，那不是KISS，只能让解决方案（或者更确切地说，workaround）更复杂。lambda函数是有用的，但假如在真正需要lambda的地方不使用lambda，也只能导致更复杂更不直观的workarounds。OOP是有用的，但假如你的程序本来就只是简单的“数据+操作”你偏要硬上OOP的话，不仅多了编码时间，而且还降低程序的可见度和可维护性，后者就意味着项目的money。拿C++来说，这是一个广为诟病的问题。C++的偏向底层的应用领域决定了有不少地方使用C++其实就是“数据+操作”，然而很多人却因为用的是C++编译器，便忍不住去使用高级特性，结果把本来简单的事情复杂化——我自己就有不少次这样的经历：用了一大堆类之后，做完了回过头来再看，这些类都干嘛来着？需要吗？最要害的就是要清楚自己做的是什么事情，以及什么工具才是对你所做的事情最适合的。
说到这里不妨顺便说说另一个误解：“假如我反正用不着C++里面的高级特性，那还不如用C罢了”，鉴于C/C++的应用领域，的确有不少地方是可以用C++的C部分完成得很好的，所以这个误解被传播得还是蛮广泛的。这里的一个微妙的忽视在于：用C的话，你就用不到许多很好的C++库了。用C++的话，你完全可以在你自己的编码中不使用高阶特性（说实话，这需要清醒的头脑和丰富的经验，以及克制能力），但你还是可以利用众多的C++库来简化你的工作的：假如一个transform明明可以搞定的你偏要写一个for出来难道能叫KISS？假如一个vector就能避免绝大多数内存治理漏洞和简化内存治理工作你偏偏要手动malloc/free那能叫KISS（我见过不少用C++编码却到处都是malloc/free的）？假如最直接的方式是gc你偏偏要绕一大堆弯子才能保证正确释放那也不叫KISS（等C++09吧）。假如一个for_each(readdir_sequence(".", readdir_sequence::files), ::remove);能搞定的你偏要写：
| // in C DIR* dir = opendir("."); if(NULL != dir) { strUCt dirent* de; for(; NULL != (de = readdir(dir)); ) { struct stat st; if( 0 == stat(de->d_name, &st) && S_IFREG == (st.st_mode & S_IFMT)) { remove(de->d_name); } } closedir(dir); } |
那能叫KISS？
总之还是那句话：明确知道你想要表达的是什么并用最简洁（在不损害轻易理解性的前提下）的方式去表达它。但我认为，最KISS不代表最原始。
进化——两个例子
先举一个平易近人的例子（Walter Bright——D语言发明者——曾在他的一个PResentation中使用这个例子），假如我们想要遍历一个数组，在C里面我们是这么做（或者用指针，不过指针有指针自己的问题）：
| int arr[10]; … // initialize arr for(int i = 0; i < 10; ++i) { int value = arr[i]; … printf } |
这个貌似简单的循环其实有几个主要的问题：
1. 下标索引不应该是int，而应该是size_t，int未必能足够存放一个数组的下标。
2. value的类型依靠于arr内元素的类型，违反DRY，假如arr的类型改变为long或unsigned，就可能发生截断。
3. 这种for只能对数组工作，假如是另一个自定义容器就不行了。
在现代C++里面，则是这么做：
| for(std::vector<int>::iterator iter = v.begin(); iter != v.end(); ++iter) { … } |
其实最大的问题就是一天三遍的写，麻烦。for循环的这个问题上篇讲auto的时候也提到。
Walter Bright然后就把D里面支持的foreach拿出来对比（当然，支持foreach的语言太多了，这也说明了这个结构的高效性）。
| foreach(i; v) { … } |
不多不少，刚好表达了意思：对v中的每个元素i做某某事情。
这个例子有人说太Na?ve了，其实我也赞成，的确，天天不知道有多少程序员写下一个个的循环结构，究竟有多少出了上面提到的三个问题呢？最大的问题恐怕还是数组越界。此外大家也都亲身体验过违反DRY原则的后果：改了一处地方的类型，编译，发现到处都是类型错误，结果一通“查找——替换”是免不了的了，谁说程序员的时间是宝贵的来着？
既然这个例子太Nave，那就说一个不那么Nave的。java为什么要加入closure？以C++STL为例，假如我们要：
transform(v1.begin(), v1.end(), v2.begin(), v3.begin(), _1 + _2);
也就是说将v1和v2里面的元素对应相加然后放到v3当中去。这里用了boost.lambda，但大家都知道boost.lambda又是一个经典的鸡肋。_1 + _2还算凑活，一旦表达式复杂了，或者其中牵涉到对其它函数的调用了，简直就是一场噩梦，比如说我们想把v1和v2中相应元素这样相加：f(_1) + f(_2)，其中f是一个函数或仿函数，可以做加权或者其它处理，那么我们可以像下面这样写吗：
transform(…, f(_1) + f(_2));
答案是不行，你得这样写：
| transform(…, boost::bind(std::plus<int>(), boost::bind(f, _1), boost::bind(f, _1)) ); |
Lisper们笑了，Haskeller们笑了，就连Javaer们都笑了。It’s not even funny! 这显然违反了“simple things should be simple”原则。
假如不想卷入C++ functional的噩梦的话，你也可以这么写：
| struct Op { int Operator()(int a1, int a2) { return f(a1) + f(a2); } }; transform(…, Op()); |
稍微好一点，但这种做法也有很严重的问题。
为什么Java加入closure，其实还是一个语法问题。从严格意义上，Java的anonymous class已经可以实现出一样的功能了，正如C++的functor一样。然而，代码是给人看的，语言是给人用来写代码的，代码的主要代价在维护，维护则需要阅读、理解。写代码的人不希望多花笔墨来写那些自己本不关心的东西，读代码的人也希望“所读即所表”，不想看到代码里面有什么弯子，最好是自然语言自然抽象才好呢。
所以，尽管closure是一颗语法糖，但却是一颗很甜很甜的糖，因为有了closure你就可以写：
| transform(…, <>(a1, a2){ f(a1) + f(a2) }); Simple things should be simple! |
此外，closure最强大的好处还是在于对局部变量的方便的引用，设想我们想要创建的表达式是：
| int weight1 = 0.3, weight2 = 0.6; transform(…, f(_1)*weight1 + f(_2)*weight2); |
当然，上面的语句是非法的，不过使用closure便可以写成：
| int weight1 = 0.3, weight2 = 0.6; transform(…, <&>(_1, _2){ f(_1)*weight1 + f(_2)*weight2 } ); |
用functor class来实现同样的功能则要麻烦许多，一旦麻烦，就会error-prone，一旦error-prone，就会消耗人力，而人力，就是金钱。
C++09也有希望加入lambda，不过这是另一个话题，下回再说。
The Real Deal——variadic templates
C++的callback类，Google一下，没有一打也有半打。其中尤数boost.function实现得最为灵活周到。然而，就在其灵活周到的接口下面，却是让人不忍卒读的实现；03年的时候我写的第一篇boost源码剖析就是boost.function的，当时还觉得能看懂那样的代码牛得不行...话说回来，那篇文章主要剖析了两个方面，一个是它对不同参数的函数类型是如何处理的，第二个是一个type-erase设施。其中第一个方面就占去了大部分的篇幅。
简而言之，要实现一个泛型的callback类，就必须实现以下最常见的应用场景：
| function<int(int, int)> caller = f; int r = caller(1, 2); // call f |
为此function类模板里面肯定要有一个operator()，然而，接下来，如何定义这个operator()就成了问题：
| template<Signature> class function { operator()(???); }; |
???处填什么？返回值处的???可以解决，用一个traits：typename result_type<Signature>::type，但参数列表处的???呢？
boost采用的办法也是C++98唯一的办法，就是为不同参数个数的Signature进行特化：
| template<typename R, typename T1> class function<R(T1)> { R operator()(T1 a1); }; template<typename R, typename T1, typename T2> class function<R(T1, T2)> { R operator()(T1 a1, T2 a2); }; template<typename R, typename T1, typename T2, typename T3> class function<R(T1, T2, T3)> { R operator()(T1 a1, T2 a2, T3 a3); }; … // 再写下去页宽不够了，打住… |
如此一共N（N由一个宏控制）个版本。
这种做法有两个问题：一，函数的参数个数始终还是受限的，你作出N个特化版本，那么对N+1个参数的函数就没辙了。boost::tuple也是这个问题。二，代码重复。每个特化版本里面除了参数个数不同之外基本其它都是相同的；boost解决这个问题的办法是利用宏，宏本身的一大堆问题就不说了，你只要打开boost.function的主体实现代码就知道有多糟糕了，近一千行代码，其中涉及元编程和宏技巧无数，可读性可以说基本为0。好在这是个标准库（boost.function将加入tr1）不用你维护，假如是你自己写了用的库，恐怕除了你谁也别想动了。所以第二个问题其实就是可读性可维护性问题，用Matthew Wilson的说法就是可发现性和透明性的问题，这是一个很严重的问题，许多C++现代库因为这个问题而遭到诟病。
现在，让我们来看一看加入了variadic templates之后的C++09实现：
| template<typename R, typename... Args> struct invoker_base { virtual R invoke(Args...) = 0; virtual ~invoker_base() { } }; template<typename F, typename R, typename... Args> struct functor_invoker : public invoker_base<R, Args...> { eXPlicit functor_invoker(F f) : f(f) { } R invoke(Args... args) { return f(args...); } private: F f; }; template<typename Signature> class function; template<typename R, typename... Args> class function<R (Args...)> { public: template<typename F> function(F f) : invoker(0) { invoker = new functor_invoker<F, R, Args...>(f); } R operator()(Args... args) const { return invoker->invoke(args...); } private: invoker_base<R, Args...>* invoker; }; |
整个核心实现就这些！一共才36行！加上析构函数拷贝构造函数等边角料一共也就70行！更重要的是，整个代码清楚无比，所有涉及到可变数目个模板参数的地方都由variadic templates代替。“Args…”恰如其分的表达了我们想要表达的意思——多个参数（数目不管）。与C++98的boost.function实现真是天壤之别！
这里function_invoker是用的type-erase手法，具体可参见我以前写的boost.any源码剖析，或上篇讲auto的，或《C++ Template Metaprogramming》（内有元编程慎入！）。type-erase手法是像C++这样的弱RTTI支持的语言中少数真正实用的手法，某种程度上设计模式里面的adapter模式也是type-erase的一个变种。
假如还觉得不够的话，可以参考variadic-templates的主页，上面的variadic templates proposal中带了三个tr1实现，分别是tuple，bind，function，当然，variadic-templates的好处远远不仅仅止于这三个实现，从本质上它提供了一种真正直接的表达意图的工具，完全避开了像下面这种horrible的workaround：
| template<class T1> cons(T1& t1, const null_type&, const null_type&, const null_type&, const null_type&, const null_type&, const null_type&, const null_type&, const null_type&, const null_type&) : head (t1) {} |
tuple的C++98实现，代码近千行。利用variadic-templates实现，代码仅百行。
和这种更horrible的workaround：
| template<class R, class F, class A1, class A2, class A3, class A4, class A5, class A6> _bi::bind_t<R, F, typename _bi::list_av_6<A1, A2, A3, A4, A5, A6>::type> BOOST_BIND(boost::type<R>, F f, A1 a1, A2 a2, A3 a3, A4 a4, A5 a5, A6 a6) { typedef typename _bi::list_av_6<A1, A2, A3, A4, A5, A6>::type list_type; return _bi::bind_t<R, F, list_type>(f, list_type(a1, a2, a3, a4, a5, a6)); } |
小小的boost.bind，实现代码逾两千行，其间重复代码无数。用了variadic-templates，实现不过百行。
BTW. variadic templates在C++大会上一次性几乎全数投票通过。lambda能不能进标准则要看几个提案者的工作。目前还没有Wording出来。不过只要出了wording想必也会像variadic templates那样压倒性通过的。
中查找“瘦身前后——兼谈C++语言进化”更多相关内容
中查找“瘦身前后——兼谈C++语言进化”更多相关内容更多精彩
赞助商链接
