• <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>

            那誰(shuí)的技術(shù)博客

            感興趣領(lǐng)域:高性能服務(wù)器編程,存儲(chǔ),算法,Linux內(nèi)核
            隨筆 - 210, 文章 - 0, 評(píng)論 - 1183, 引用 - 0
            數(shù)據(jù)加載中……

            解讀google C++ code style談對(duì)C++的理解

            C++是一門(mén)足夠復(fù)雜的語(yǔ)言.說(shuō)它"足夠復(fù)雜",是因?yàn)镃++提供了足夠多編程范式--泛型, 模板, 面向?qū)ο? 異常,等等.順便說(shuō)說(shuō),我已經(jīng)很久沒(méi)有跟進(jìn)C++的最新發(fā)展了(比如C++0x), 所以前面列舉出來(lái)的特性應(yīng)該只是C++所有特性的一個(gè)部分罷了.C++特性過(guò)多很難駕馭好C++的原因之一.另一個(gè)原因是C++過(guò)于"自作聰明",在很多地方悄無(wú)聲息的做了很多事情, 比如隱式的類(lèi)型轉(zhuǎn)換, 重載, 模板推導(dǎo)等等.而很多時(shí)候,這些動(dòng)作難以察覺(jué),有時(shí)候會(huì)在你意想不到的地方發(fā)生,即使是熟練的C++程序員也難免被誤傷.(關(guān)于了解C++編譯器自作聰明做了哪些事情, <<深入理解C++物件模型>>是不錯(cuò)的選擇).

            世界上有很多問(wèn)題, 人們知道如何去解決.但是, 似乎這還不算是最高明的,更高明的做法是學(xué)會(huì)避免問(wèn)題的發(fā)生.而如何避免問(wèn)題的發(fā)生, 需要經(jīng)驗(yàn)的積累--曾經(jīng)犯下錯(cuò)誤,吃一塹長(zhǎng)一智,于是知道哪些事情是不該做的或者是不應(yīng)該這么做的.

            google C++ code style是google對(duì)外公布的一份google內(nèi)部編寫(xiě)C++的代碼規(guī)范文檔.與其他很多我曾經(jīng)看過(guò)的編碼文檔一樣,里面有一些關(guān)于代碼風(fēng)格的規(guī)定,也就是代碼的外觀,這一部分不在這里過(guò)多討論,畢竟代碼如何才叫"美觀"是一個(gè)見(jiàn)仁見(jiàn)智的話(huà)題.在這里專(zhuān)門(mén)討論這份文檔中對(duì)一些C++特性該如何使用的討論,最后再做一個(gè)總結(jié).注意其中的序號(hào)并不是文檔中的序號(hào),如果要詳細(xì)了解,可以自己去看這份文檔.

            1) Static and Global Variables
               Static or global variables of 
            class type are forbidden: they cause hard-to-find bugs due to indeterminate order of construction and destruction.
            google明確禁止全局對(duì)象是類(lèi)對(duì)象, 只能是所謂POD(Plain Old Data,如int char等)數(shù)據(jù)才行.因?yàn)镃++標(biāo)準(zhǔn)中沒(méi)有明確規(guī)定全局對(duì)象的初始化順序, 假設(shè)全局類(lèi)對(duì)象A,B,其中A的初始化依賴(lài)于B的值, 那么將無(wú)法保證最后的結(jié)果.如果非要使用全局類(lèi)對(duì)象, 那么只能使用指針, 在main等函數(shù)入口統(tǒng)一進(jìn)行初始化.

            2) Doing Work in Constructors
            In general, constructors should merely 
            set member variables to their initial values. Any complex initialization should go in an explicit Init() method. 
            文檔規(guī)定, 在類(lèi)構(gòu)造函數(shù)中對(duì)類(lèi)成員對(duì)象做基本的初始化操作, 所有的復(fù)雜初始化操作集中一個(gè)比如Init()的函數(shù)中,理由如下:
            • There is no easy way for constructors to signal errors, short of using exceptions (which are forbidden).
            • If the work fails, we now have an object whose initialization code failed, so it may be an indeterminate state.
            • If the work calls virtual functions, these calls will not get dispatched to the subclass implementations. Future modification to your class can quietly introduce this problem even if your class is not currently subclassed, causing much confusion.
            • If someone creates a global variable of this type (which is against the rules, but still), the constructor code will be called before main(), possibly breaking some implicit assumptions in the constructor code. For instance, gflags will not yet have been initialized.
            簡(jiǎn)單的概括起來(lái)也就是:構(gòu)造函數(shù)沒(méi)有返回值, 難以讓使用者感知錯(cuò)誤;假如在構(gòu)造函數(shù)中調(diào)用虛擬函數(shù), 則無(wú)法按照使用者的想法調(diào)用到對(duì)應(yīng)子類(lèi)中實(shí)現(xiàn)的虛擬函數(shù)(理由是構(gòu)造函數(shù)還未完成意味著這個(gè)對(duì)象還沒(méi)有被成功構(gòu)造完成).

            3) Default Constructors
            You must define a 
            default constructor if your class defines member variables and has no other constructors. Otherwise the compiler will do it for you, badly. 
            當(dāng)程序員沒(méi)有為類(lèi)編寫(xiě)一個(gè)默認(rèn)構(gòu)造函數(shù)的時(shí)候, 編譯器會(huì)自動(dòng)生成一個(gè)默認(rèn)構(gòu)造函數(shù),而這個(gè)編譯器生成的函數(shù)如何實(shí)現(xiàn)(比如如何初始化類(lèi)成員對(duì)象)是不確定的.這樣,假如出現(xiàn)問(wèn)題時(shí)將給調(diào)試跟蹤帶來(lái)困難.所以, 規(guī)范要求每個(gè)類(lèi)都需要編寫(xiě)一個(gè)默認(rèn)構(gòu)造函數(shù)避免這種情況的出現(xiàn).

            4) Explicit Constructors
            Use the C
            ++ keyword explicit for constructors with one argument.
            假如構(gòu)造函數(shù)只有一個(gè)參數(shù), 使用explicit避免隱式轉(zhuǎn)換, 因?yàn)殡[式轉(zhuǎn)換可能在你并不需要的時(shí)候出現(xiàn).

            5) Copy Constructors
            Provide a copy constructor and assignment 
            operator only when necessary. Otherwise, disable them with DISALLOW_COPY_AND_ASSIGN.
            只有當(dāng)必要的時(shí)候才需要定義拷貝構(gòu)造函數(shù)和賦值操作符. 同上一條理由一樣, 避免一些隱式的轉(zhuǎn)換.另一條理由是,"="難以跟蹤,如果真的要實(shí)現(xiàn)類(lèi)似的功能,可以提供比如名為Copy()的函數(shù),這樣子一目了然,不會(huì)像賦值操作符那樣可能在每個(gè)"="出現(xiàn)的地方出現(xiàn).

            6) Operator Overloading
            Do not overload operators except 
            in rare, special circumstances.
            不要重載操作符.同樣, 也是避免莫名其妙的調(diào)用了一些函數(shù).同上一條一樣, 比如要提供對(duì)"=="的重載, 可以提供一個(gè)名為Equal()的函數(shù), 如果需要提供對(duì)"+"的重載, 可以提供一個(gè)名為Add()的函數(shù).

            7) Function Overloading
            Use overloaded functions (including constructors) only 
            in cases where input can be specified in different types that contain the same information. Do not use function overloading to simulate default function parameters.
            只有在不同的類(lèi)型表示同樣的信息的時(shí)候, 可以使用重載函數(shù).其他情況下,一律不能使用.使用重載, 也可能出現(xiàn)一些隱式出現(xiàn)的轉(zhuǎn)換.所以, 在需要對(duì)不同函數(shù)進(jìn)行同樣操作的時(shí)候, 可以在函數(shù)名稱(chēng)上進(jìn)行區(qū)分, 而不是使用重載,如可以提供針對(duì)string類(lèi)型的AppendString()函數(shù), 針對(duì)int類(lèi)型的AppendInt()函數(shù),而不是對(duì)string和int類(lèi)型重載Append()函數(shù).另一個(gè)好處在于, 在閱讀代碼時(shí),通過(guò)函數(shù)名稱(chēng)可以一目了然.

            8) Exceptions
            We 
            do not use C++ exceptions.
            不使用異常.理由如下:
            • When you add a throw statement to an existing function, you must examine all of its transitive callers. Either they must make at least the basic exception safety guarantee, or they must never catch the exception and be happy with the program terminating as a result. For instance, if f() calls g() calls h(), and h throws an exception that f catches, g has to be careful or it may not clean up properly.
            • More generally, exceptions make the control flow of programs difficult to evaluate by looking at code: functions may return in places you don't expect. This results maintainability and debugging difficulties. You can minimize this cost via some rules on how and where exceptions can be used, but at the cost of more that a developer needs to know and understand.
            • Exception safety requires both RAII and different coding practices. Lots of supporting machinery is needed to make writing correct exception-safe code easy. Further, to avoid requiring readers to understand the entire call graph, exception-safe code must isolate logic that writes to persistent state into a "commit" phase. This will have both benefits and costs (perhaps where you're forced to obfuscate code to isolate the commit). Allowing exceptions would force us to always pay those costs even when they're not worth it.
            • Turning on exceptions adds data to each binary produced, increasing compile time (probably slightly) and possibly increasing address space pressure.
            • The availability of exceptions may encourage developers to throw them when they are not appropriate or recover from them when it's not safe to do so. For example, invalid user input should not cause exceptions to be thrown. We would need to make the style guide even longer to document these restrictions!
            上面提到的理由中, 我認(rèn)為使用異常最大的害處就是:異常的使用導(dǎo)致了程序無(wú)法按照代碼所展現(xiàn)的流程去走的, 比如代碼里面寫(xiě)了步驟一二三,但是假如有異常出現(xiàn), 這就不好預(yù)知代碼真正步進(jìn)的步驟了, 在出現(xiàn)問(wèn)題時(shí), 給調(diào)試和跟蹤帶來(lái)困難.
            另外, 我更喜歡unix API的設(shè)計(jì).熟悉unix編程的人都知道, unix API基本上都遵守下列規(guī)則:
            a) 返回0表示成功, 其他(一般是-1)表示失敗.
            b) 在失敗時(shí), 可以根據(jù)errno判斷失敗的原因, 這些在man手冊(cè)中都是會(huì)清楚的描述.

            總結(jié)一下, 這份規(guī)范中規(guī)避的C++特性大致分為以下幾類(lèi):
            a) 避免使用那些沒(méi)有確定行為的特性:如全局變量不能是類(lèi)對(duì)象(初始化順序不確定), 不使用編譯器生成的默認(rèn)構(gòu)造函數(shù)(構(gòu)造行為不確定), 異常(代碼走向不確定).
            b) 避免使用那些隱式發(fā)生的操作:如聲明單參數(shù)構(gòu)造函數(shù)為explict以避免隱式轉(zhuǎn)換, 不定義拷貝構(gòu)造函數(shù)避免隱式的拷貝行為, 不使用操作符重載避免隱式的轉(zhuǎn)換
            c) 對(duì)模棱兩可的特性給予明確的規(guī)定:不使用函數(shù)重載而是定義對(duì)每個(gè)類(lèi)型明確的函數(shù).
            d) 即使出錯(cuò)了程序也有辦法知道: 比如不能在類(lèi)構(gòu)造函數(shù)中進(jìn)行復(fù)雜的構(gòu)造操作, 將這些移動(dòng)到類(lèi)Init()的函數(shù)中.

            同時(shí), 這份文檔中描述的大部分C++特性, 都是我之前所熟悉的(除了RTTI之外, 不過(guò)這里提到它也是要說(shuō)明不使用它,另外還提到boost, 不過(guò)也是說(shuō)的要對(duì)它"有限制"的使用,比如里面的智能指針).可以看到, 面對(duì)這樣一門(mén)復(fù)雜同時(shí)還在不停的發(fā)展更新特性的語(yǔ)言, google的態(tài)度是比較"保守"的.這與我之前對(duì)C++的理解也是接近的, 我一直認(rèn)為C++中需要使用到的特性有基本的面向?qū)ο?STL就夠了(經(jīng)過(guò)最近的編碼實(shí)踐,我認(rèn)為還得加個(gè)智能指針).我對(duì)這個(gè)"保守"態(tài)度的理解是, 以C++當(dāng)前的應(yīng)用場(chǎng)景來(lái)看, 這些特性已經(jīng)足夠, 如果使用其他一些更加復(fù)雜的, 對(duì)人的要求提高了, 代碼的可讀性以及以后的可維護(hù)性就下降了.

            前面說(shuō)過(guò), 避免問(wèn)題的出現(xiàn)比解決問(wèn)題來(lái)的更加高明些, 而面對(duì)C++這一個(gè)提供了眾多特性, google C++ code style給予了明確的規(guī)定, 也就是每個(gè)行為, 如果都能做到有明確的動(dòng)作, 同時(shí)結(jié)果也都是可以預(yù)知的, 那么會(huì)將出問(wèn)題的概率最大可能的降低, 即使出了問(wèn)題, 也容易跟蹤.

            上面描述的并不是這份文檔中有關(guān)C++的所有內(nèi)容, 只不過(guò)我覺(jué)得這些更加有同感些, 詳細(xì)的內(nèi)容, 可以參看這份文檔.都知道google的作品,質(zhì)量有保證, 除了人的素質(zhì)確實(shí)高之外, 有規(guī)范的制度保證也是重要的原因, 畢竟只要是人就會(huì)犯錯(cuò), 為了最大限度的避免人犯錯(cuò), 有一份詳盡的代碼規(guī)范, 寫(xiě)好哪些該做哪些不該做哪些不該這么做, 也是制度上的保證.另外, 假如每個(gè)人都能以一個(gè)比較高的標(biāo)準(zhǔn)要求自己所寫(xiě)的代碼, 久而久之, 獲得進(jìn)步也是必然的結(jié)果.

            從這套規(guī)范里面, 我的另一個(gè)感悟是, 不論是什么行業(yè), "學(xué)會(huì)如何正確的做事情", 都是十分必要的.這個(gè)"正確的做事情", 具體到編碼來(lái)說(shuō), 就是代碼規(guī)范里面提到的那些要求.而除去編碼, 做任何的事情, 使用正確的方式做事, 都是盡可能少的避免錯(cuò)誤的方法.但是, "錯(cuò)"與"對(duì)"是相對(duì)而言的, 沒(méi)有之前"錯(cuò)"的經(jīng)歷, 就不好體會(huì)什么叫"對(duì)".所以, "如何正確的做事", 說(shuō)到了最后, 還得看個(gè)人的經(jīng)驗(yàn)積累, 有了之前"錯(cuò)誤"的經(jīng)歷,才能吃一塹長(zhǎng)一智, "錯(cuò)誤"并不是一無(wú)是處的, 只不過(guò), 并不是誰(shuí)都去嘗試著從中學(xué)習(xí).


            posted on 2010-05-29 20:34 那誰(shuí) 閱讀(38167) 評(píng)論(43)  編輯 收藏 引用 所屬分類(lèi): C\C++

            評(píng)論

            # re: 解讀google C++ code style談對(duì)C++的理解  回復(fù)  更多評(píng)論   

            因噎廢食
            2010-05-29 22:59 | OwnWaterloo

            # re: 解讀google C++ code style談對(duì)C++的理解  回復(fù)  更多評(píng)論   

            @OwnWaterloo
            又學(xué)了一個(gè)成語(yǔ)"因噎廢食 ( yīn yē fèi shí )":原意是說(shuō),因?yàn)橛腥顺燥堃×耍餍赃B飯也不吃了,這太荒謬了。比喻要做的事情由于出了點(diǎn)小毛病或怕出問(wèn)題就索性不去干

            能解釋一下在這里針對(duì)這個(gè)帖子做這個(gè)回復(fù)的含義么?

            2010-05-29 23:02 | 那誰(shuí)

            # re: 解讀google C++ code style談對(duì)C++的理解  回復(fù)  更多評(píng)論   

            @那誰(shuí)
            "C++某特性不理解,產(chǎn)生畏錯(cuò)心理(或者已經(jīng)得到教訓(xùn));
            對(duì)此采取的措施不是去學(xué)習(xí)與理解這些特性, 而是放棄這些特性。"


            對(duì)筷子不熟悉,不嘗試學(xué)習(xí)與熟練,而是放棄 —— 這也不是不行, 畢竟用刀叉(甚至手抓)也算是吃飯 —— 但是, 如果是中餐的話(huà), 這并不是什么值得為之感到光榮的事。


            吃飯不同于軟件開(kāi)發(fā)的地方是:
            餐桌上的同伴吃中餐不用筷子最多最多讓人感到難堪。
            而項(xiàng)目中的隊(duì)員如果做不到步調(diào)一致, 就可能導(dǎo)致項(xiàng)目失敗。
            但是, 相比這飯吃得是否得體, 步調(diào)一致更為重要。
            所以, 為了那些因噎廢食的人, 不得不同他們一起"吃手抓飯", 從而達(dá)到步調(diào)一致, 也是很無(wú)奈的事。
            —— 這依然不是什么值得炫耀的事情。


            在正??刂屏髦胁迦氲牧硪粭l控制流是異常的關(guān)鍵。
            正是這條非尋常的控制流, 導(dǎo)致學(xué)習(xí)成本。
            如果愿意去學(xué)習(xí)這條控制流的規(guī)則, 就能得到這條控制流帶來(lái)的好處:
            它確實(shí)將“錯(cuò)誤的檢測(cè)與處理”給分開(kāi)了。
            —— 中餐是否值得吃,就是在學(xué)習(xí)成本與所有層次上的所有錯(cuò)誤都必須“手工地”檢測(cè)并向上報(bào)告(即使不處理任何錯(cuò)誤)之前做選擇。


            越來(lái)越多的語(yǔ)言加入異常處理機(jī)制(甚至是一些原本沒(méi)有的語(yǔ)言)。
            并且, 在正??刂屏髦獾目刂屏鞑⒉恢辉诋惓L幚碇谐霈F(xiàn): 信號(hào), thread_cancel都有,

            要么“永遠(yuǎn)逃避所有使用非正??刂屏鞯募夹g(shù)”。
            —— 永遠(yuǎn)不去學(xué)習(xí)如何使用筷子。

            要么去學(xué)習(xí)任意一種, 并舉一反三。
            —— 學(xué)習(xí)筷子的使用后, 品嘗中餐的諸多菜系都有基礎(chǔ)了。


            關(guān)于google, 我感到困惑的是: 對(duì)google中的python和java程序員是否也有不許使用異常的規(guī)定。
            我想應(yīng)該是沒(méi)有的。
            那么, 換來(lái)的結(jié)論就是: goolge中的C++程序員, 對(duì)異常這種編程思想的理解, 還不如google中的python和java程序員。
            2010-05-29 23:59 | OwnWaterloo

            # re: 解讀google C++ code style談對(duì)C++的理解  回復(fù)  更多評(píng)論   

            @那誰(shuí)
            一說(shuō)就起勁了……

            再說(shuō)說(shuō)操作符重載。 equals add vs ==, +

            記號(hào)系統(tǒng)的嚴(yán)謹(jǐn)與簡(jiǎn)潔都很重要。
            以前我也只注重記號(hào)系統(tǒng)的嚴(yán)謹(jǐn), 認(rèn)為嚴(yán)謹(jǐn)?shù)木褪且鬃x、易理解的。
            直到讀了這篇文章:
            http://www.ibm.com/developerworks/cn/xml/x-matters/part24/index.html

            清單3中的xml就是嚴(yán)謹(jǐn)而不簡(jiǎn)潔的。 即使不學(xué)習(xí)任何新事物, 也大致能猜出清單3表示的是什么內(nèi)容。
            而清單2的記號(hào)系統(tǒng)就是簡(jiǎn)潔的, 同時(shí)也是嚴(yán)謹(jǐn)?shù)?—— 只是需要學(xué)習(xí)這套記號(hào)系統(tǒng)。

            如果不學(xué)習(xí)清單2中的記號(hào)系統(tǒng), 那清單2可能就是天書(shū)。
            如果學(xué)習(xí)了, 那清單2就幾乎是"用極少?gòu)U話(huà)作輔助, 表達(dá)作者的意思"。

            而清單3,無(wú)論是否學(xué)習(xí), 都是很羅嗦的在表達(dá)作者的含義, 包含了太多的噪音。

            我覺(jué)得(只是覺(jué)得, 因?yàn)闅v史不能重演), 如果微積分的記號(hào)系統(tǒng)不是隨微積分一起產(chǎn)生, 微積分是發(fā)展不起來(lái)的。
            將表達(dá)式中的Sx 全部替換成 interal(x); 記號(hào)是不需要學(xué)了, 但這表達(dá)式根本沒(méi)法讀。

            所以, 不是簡(jiǎn)潔的記號(hào)系統(tǒng)不可取, 而是記號(hào)系統(tǒng)在簡(jiǎn)潔的同時(shí)還要保持直觀, 嚴(yán)謹(jǐn), 無(wú)歧義。
            要設(shè)計(jì)出這樣的記號(hào)系統(tǒng)是需要精心的、 全局的、 周詳?shù)臏?zhǔn)備。
            而C++的操作符重載讓記號(hào)的引入變得太容易, 獲得簡(jiǎn)潔的同時(shí)容易丟失其他方面的因素。

            上面回復(fù)已經(jīng)說(shuō)到google中C++程序員的素質(zhì)。
            與其于讓他們理解直觀、嚴(yán)謹(jǐn)、無(wú)歧義, 直接讓他們不許使用新的記號(hào)系統(tǒng)可能更省事。
            但無(wú)論如何, 這所謂的"高標(biāo)準(zhǔn)"的規(guī)范, 其實(shí)只是"無(wú)奈"之舉, 而非"進(jìn)步"。
            2010-05-30 00:23 | OwnWaterloo

            # re: 解讀google C++ code style談對(duì)C++的理解  回復(fù)  更多評(píng)論   

            目前 Google 公開(kāi)的大量 C++ 代碼都遵循了這份規(guī)范。
            這些公開(kāi)的代碼的質(zhì)量都很高,值得借鑒。
            2010-05-30 08:36 | 陳碩

            # re: 解讀google C++ code style談對(duì)C++的理解  回復(fù)  更多評(píng)論   

            @OwnWaterloo
            那你能對(duì)規(guī)范中描述的異常的缺陷進(jìn)行回復(fù)么?我里面提到的,由于引入了異常,導(dǎo)致代碼走向難以預(yù)測(cè),這一點(diǎn)如何解決?類(lèi)似unix API那樣的,根據(jù)返回值判斷是否成功,根據(jù)errno判斷失敗原因,是非常簡(jiǎn)潔明了的做法,我更傾向于設(shè)計(jì)出這樣的API.
            2010-05-30 08:43 | 那誰(shuí)

            # re: 解讀google C++ code style談對(duì)C++的理解  回復(fù)  更多評(píng)論   

            @OwnWaterloo
            另外,我見(jiàn)到的google開(kāi)源出來(lái)的python代碼不多,java我不會(huì),就更沒(méi)看過(guò)了,但是這份python代碼:
            http://google-styleguide.googlecode.com/svn/trunk/cpplint/cpplint.py
            里面似乎就沒(méi)有使用到異常.
            2010-05-30 08:45 | 那誰(shuí)

            # re: 解讀google C++ code style談對(duì)C++的理解  回復(fù)  更多評(píng)論   

            @那誰(shuí)
            "我里面提到的,由于引入了異常,導(dǎo)致代碼走向難以預(yù)測(cè),這一點(diǎn)如何解決?"
            你這個(gè)問(wèn)題就像:
            由于引入了指針(甚至雙指針), 導(dǎo)致代碼難以理解,充滿(mǎn)bug, 這一點(diǎn)應(yīng)該如何解決?
            難道我們應(yīng)該放棄指針(和雙指針)?

            "指針"還可以替換成很多東西。

            一句話(huà), 不學(xué), 什么都難以理解。
            如何解決?
            1. 讓代碼保持異常安全 —— 無(wú)論異常是否發(fā)生。
            什么游戲都需要規(guī)則,這是使用異常的最關(guān)鍵規(guī)則。
            pthread_cancel有相應(yīng)的cancellation safety。
            信號(hào)有相應(yīng)的可重入。

            2. 如果沒(méi)有異常需要處理, 讓異常直接向上報(bào)告 —— 無(wú)須任何額外代碼
            而使用狀態(tài)代碼, 即使某個(gè)層次不能處理錯(cuò)誤, 也必須編寫(xiě)代碼去檢測(cè), 并向上報(bào)告(除非想吞掉這個(gè)錯(cuò)誤)。
            "每一層", "每一個(gè)調(diào)用點(diǎn)"。

            狀態(tài)代碼不優(yōu)美的地方之一 —— 太多重復(fù)代碼, 這些代碼并不是為了處理這個(gè)錯(cuò)誤, 僅僅是為了向上報(bào)告錯(cuò)誤, 所以不得不編寫(xiě)代碼去檢測(cè)。

            不優(yōu)美的地方之二 —— 檢測(cè)代碼和happy path代碼混雜在一起, 使得happy path中至少一半代碼都是和邏輯無(wú)關(guān)的, 所謂的噪音。
            上面記號(hào)系統(tǒng)中說(shuō)過(guò), 積分記號(hào)確實(shí)需要學(xué)習(xí)成本, 但換來(lái)的好處就是用最少的噪音表達(dá)出盡可能多的信息。

            不優(yōu)美的地方之三 —— caller和callee之間報(bào)告錯(cuò)誤所使用契約的耦合。
            當(dāng)caller是一個(gè)普通的函數(shù)這個(gè)問(wèn)題還不突出。當(dāng)caller是一個(gè)函數(shù)模板, 對(duì)應(yīng)的callee根本不知道是何物時(shí), 如何定義callee和caller之間的報(bào)告錯(cuò)誤的契約?
            "0表示Ok, 非0表示有問(wèn)題, 問(wèn)題寫(xiě)在errno" 而errno這種全局的東西帶有全局的一切毛病, 比如:如何分配一個(gè)獨(dú)一無(wú)二的code?

            3. 如果需要處理當(dāng)中的部分異常, try之, 并僅僅catch感興趣的異常, 處理之。
            接上面的, 如果不能得到一個(gè)獨(dú)一無(wú)二的code, 就無(wú)法知道究竟是出了什么毛病。
            EINVAL? 哪一個(gè)參數(shù)有問(wèn)題? 什么問(wèn)題? 信息早就丟了。
            無(wú)法有針對(duì)性的進(jìn)行處理。


            更多的, 請(qǐng)看:
            http://blog.csdn.net/pongba/archive/2007/10/08/1815742.aspx


            而google coding style中所謂的不使用exception的理由, 在知道什么是異常處理的人的眼中, 只有最后2點(diǎn)是站得住腳的:
            最后一點(diǎn), 也就是上一個(gè)回復(fù)說(shuō)的"與其規(guī)定什么時(shí)候可以用, 應(yīng)該如何用", 不如直接"全面禁止" —— 因噎廢食。

            倒數(shù)第2點(diǎn), 就是效率問(wèn)題。 在"效率攸關(guān)"的地方, 確實(shí)不能用。
            但這種地方并不是想象中的那么多。

            其他都是扯談。 要么寫(xiě)這個(gè)規(guī)范的人不懂exception, 要么就是他懂, 但故意牽強(qiáng)附會(huì), 或者危言聳聽(tīng)。


            另外, 這種高壓政策下的google的代碼我沒(méi)看過(guò), 所以無(wú)法評(píng)論其質(zhì)量高低。
            但肯定是"原始且不美觀"的。
            而這種在高壓政策下產(chǎn)生出的"原始且不美觀"的其他代碼我倒是看過(guò), 例如OpenCV和apr中的內(nèi)存管理部分 —— 在這種"泯滅人類(lèi)的思維與創(chuàng)造性, 僅僅將人作為制造code的工具"的高壓政策下壓榨出的代碼, 質(zhì)量怎么可能高?
            2010-05-30 20:11 | OwnWaterloo

            # re: 解讀google C++ code style談對(duì)C++的理解  回復(fù)  更多評(píng)論   

            @OwnWaterloo
            我反對(duì)你以偏概全將使用異常的態(tài)度推及到指針使用,這不是具體問(wèn)題具體分析的態(tài)度.
            其次,你的語(yǔ)氣有些過(guò)于狂妄了.就結(jié)果而言,google出品的這些軟件,雖然大部分都看不到代碼,從使用的角度看,質(zhì)量是有目共睹的,反之看它們的一些規(guī)定做法,有可取之處,而不是像你所言的"質(zhì)量怎么可能高".
            我還是堅(jiān)持我的看法,異常的使用導(dǎo)致了程序的走向難以從代碼中一目了然的看出來(lái),給問(wèn)題定位帶來(lái)困難.
            2010-05-30 20:33 | 那誰(shuí)

            # re: 解讀google C++ code style談對(duì)C++的理解  回復(fù)  更多評(píng)論   

            @那誰(shuí)
            我說(shuō)的是OpenCV和apr的內(nèi)存管理部分的質(zhì)量, 請(qǐng)仔細(xì)看。

            還是那句話(huà): 不學(xué), 什么都困難。
            這種所謂的"C++應(yīng)該避免使用異常"和java程序員所謂的"應(yīng)該避免使用指針, 所以我們使用java"有什么區(qū)別?


            "異常的使用導(dǎo)致了程序的走向難以從代碼中一目了然的看出來(lái),給問(wèn)題定位帶來(lái)困難." —— 而這才是你的偏見(jiàn)。
            就你這句話(huà)就能推斷你沒(méi)什么使用異常的經(jīng)驗(yàn), 而是出于對(duì)異常的不理解與恐懼。
            請(qǐng)問(wèn)我說(shuō)錯(cuò)沒(méi)有?
            2010-05-30 20:42 | OwnWaterloo

            # re: 解讀google C++ code style談對(duì)C++的理解  回復(fù)  更多評(píng)論   

            @OwnWaterloo
            異常少量使用過(guò),已經(jīng)基本不用,觀點(diǎn)已經(jīng)在前面闡述過(guò).如果一個(gè)特性,我認(rèn)為會(huì)給我?guī)?lái)困擾,同時(shí)目前所掌握的,已經(jīng)可以滿(mǎn)足我的需求,為什么我還要花時(shí)間去多學(xué)呢.有時(shí)候選擇過(guò)多,反而會(huì)帶來(lái)困擾吧.這個(gè)是我的觀點(diǎn),無(wú)意強(qiáng)加于誰(shuí)身上.同時(shí),他人也無(wú)需強(qiáng)加于我身上.

            "另外, 這種高壓政策下的google的代碼我沒(méi)看過(guò), 所以無(wú)法評(píng)論其質(zhì)量高低。
            但肯定是"原始且不美觀"的。"

            這句話(huà)里面的語(yǔ)調(diào),我個(gè)人認(rèn)為過(guò)于狂妄了,呵呵.

            如果你不能心平氣和的討論問(wèn)題,而使用一些自己臆斷的詞匯去描述,比如"原始切不美觀","質(zhì)量怎么可能高",我個(gè)人認(rèn)為繼續(xù)下去的意義不大.
            2010-05-30 20:50 | 那誰(shuí)

            # re: 解讀google C++ code style談對(duì)C++的理解  回復(fù)  更多評(píng)論   

            @那誰(shuí)
            java程序員也可以說(shuō)自己"基本用不著指針", "手工內(nèi)存管理給我?guī)?lái)了很多困擾"。

            是否美觀并不是我臆斷, 這可以使用完成同樣功能(當(dāng)然, 除了效率、以及二進(jìn)制兼容行上不同)的代碼進(jìn)行對(duì)比。 只是cppblog對(duì)貼代碼并不友好。
            所以, 我給出了劉未鵬一篇文章的鏈接。
            里面有完成同樣事情, 錯(cuò)誤代碼如何做 vs 異常如何做 的代碼片段。

            如果你對(duì)異常處理沒(méi)經(jīng)驗(yàn), 錯(cuò)誤代碼肯定很有經(jīng)驗(yàn)吧?
            1. 即使不能處理, 也必須檢測(cè) —— 因?yàn)樾枰蛏蠈訄?bào)告
            2. 這些檢測(cè), 重復(fù)出現(xiàn)在每個(gè)層次, 每個(gè)調(diào)用點(diǎn)
            3. 檢測(cè)代碼與邏輯代碼混雜
            4. 即使錯(cuò)誤最終報(bào)告到一個(gè)可以處理的層次, 信息早就丟得7788了, 只剩下EINVAL這種含義模糊, 不知道應(yīng)該如何應(yīng)對(duì)的錯(cuò)誤代碼。

            這些是否是實(shí)情?難道你不覺(jué)得這些手工的機(jī)械重復(fù)是不美觀的?
            而異常處理就是為了解決這些問(wèn)題。


            原始也不是臆斷。 理由上面也有: 越來(lái)越多的語(yǔ)言開(kāi)始加入異常機(jī)制。
            C++很早就加入了, 卻被程序員不分青紅皂白的拒之門(mén)外, 是否原始?
            2010-05-30 21:05 | OwnWaterloo

            # re: 解讀google C++ code style談對(duì)C++的理解  回復(fù)  更多評(píng)論   

            其實(shí)我覺(jué)得google禁止異常可能是處于與C代碼互操作困難的考慮,而不僅僅是新特性帶來(lái)的問(wèn)題。如果是最終程序那怎么都好說(shuō),但作為一個(gè)庫(kù),跟其他代碼如何進(jìn)行跨編譯單元的異常傳遞和處理恐怕不是那么簡(jiǎn)單。這是C++保留C連接能力必須付出的代價(jià)。而java顯然沒(méi)有這種問(wèn)題。
            2010-05-31 16:45 | ptptt5

            # re: 解讀google C++ code style談對(duì)C++的理解  回復(fù)  更多評(píng)論   

            額。。。最后一個(gè)。。。
            2010-05-31 17:33 | 欣萌

            # re: 解讀google C++ code style談對(duì)C++的理解  回復(fù)  更多評(píng)論   

            @那誰(shuí)
            @OwnWaterloo
            1.在我的眼里,throw就如同if,如同for,如同while,如同break,如同continue,如同return,僅僅是一種跳轉(zhuǎn)機(jī)制。

            2.市面上所說(shuō)的throw的危險(xiǎn)程度,排除了因?yàn)槌绦騿T的畏懼而不學(xué)習(xí)之外,唯一說(shuō)的過(guò)去的無(wú)非就是throw很難在ABI上得到兼容。不過(guò)google在服務(wù)器端編譯,因此不存在這種問(wèn)題。存在的話(huà)是google的代碼版本管理(這其中也包含編工具版本管理)的缺陷而不是throw的缺陷

            3.throw帶來(lái)類(lèi)型系統(tǒng)的美,帶來(lái)錯(cuò)誤與處理的解耦。就如同linus所說(shuō),因?yàn)镃++太難學(xué)(對(duì)于他本人可能不一定),因此禁止在linux里面使用C++。google的意思可能也是如此。我說(shuō)的僅僅是可能,因?yàn)镃++高手不多,反正招進(jìn)去的都不太信任,所以干脆就禁掉算了。Microsoft相反,不會(huì)就學(xué)。

            4.throw在學(xué)術(shù)上也是一個(gè)優(yōu)美的類(lèi)型系統(tǒng)的范例。當(dāng)然這跟我們開(kāi)發(fā)項(xiàng)目可能沒(méi)什么大的關(guān)系,但這卻是必然會(huì)出現(xiàn)的。原因我就不多說(shuō)了,因?yàn)橐彩欠枪こ痰摹2贿^(guò)隨著越來(lái)越多的語(yǔ)言出現(xiàn),我們看可以看到基本上所有東西都支持異常,而且也用得很好,為啥就唯獨(dú)C++不行呢?因?yàn)樗麄冃睦餂](méi)譜,沒(méi)有catch(Exception e)這種萬(wàn)能東西可以用,而且團(tuán)隊(duì)也不肯花成本去研究所使用的框架的異常規(guī)則并制定他們自己的異常守則(沒(méi)時(shí)間估計(jì)是一個(gè)原因,像google和baidu和bing這類(lèi)公司底下員工加班已成慣例),所以最賺錢(qián)的辦法就是——禁止

            結(jié)論:google禁止異常比較省錢(qián)。
            2010-05-31 19:22 | 陳梓瀚(vczh)

            # re: 解讀google C++ code style談對(duì)C++的理解  回復(fù)  更多評(píng)論   

            @陳梓瀚(vczh)

            >>1.在我的眼里,throw就如同if,如同for,如同while,如同break,如同continue,如同return,僅僅是一種跳轉(zhuǎn)機(jī)制。
            而且, 這種跳轉(zhuǎn)機(jī)制我認(rèn)為比goto/longjmp要好理解, 因?yàn)樗墙Y(jié)構(gòu)化的。

            >>2.市面上所說(shuō)的throw的危險(xiǎn)程度,排除了因?yàn)槌绦騿T的畏懼而不學(xué)習(xí)之外,唯一說(shuō)的過(guò)去的無(wú)非就是throw很難在ABI上得到兼容。
            嗯, exception真正從技術(shù)上不能被使用的原因就只有效率和二進(jìn)制兼容性。
            其他都是"人文原因", "市場(chǎng)原因","成本原因", "金錢(qián)原因"。

            btw: 你發(fā)覺(jué)C++的二進(jìn)制兼容性會(huì)闖禍了~?


            >>4. ... 因?yàn)樗麄冃睦餂](méi)譜,沒(méi)有catch(Exception e)這種萬(wàn)能東西可以用 ...
            這倒不難, 敢用exception肯定要人為規(guī)定一個(gè)最終基類(lèi)。
            即使沒(méi)有這樣的基類(lèi), 還可以catch( ... )
            2010-05-31 21:48 | OwnWaterloo

            # re: 解讀google C++ code style談對(duì)C++的理解  回復(fù)  更多評(píng)論   

            @OwnWaterloo
            我一直都知道兼容性有問(wèn)題,但是一個(gè)團(tuán)隊(duì)使用相同的編譯器是應(yīng)該的,而且如果他們使用開(kāi)源的庫(kù)的話(huà),自己編譯更加安全。

            其他語(yǔ)言的Exception都有Message,這個(gè)可是好東西啊……而且catch(...)不能處理基本錯(cuò)誤,譬如說(shuō)access violation,還有divided by zero等等。
            2010-05-31 23:17 | 陳梓瀚(vczh)

            # re: 解讀google C++ code style談對(duì)C++的理解  回復(fù)  更多評(píng)論   

            @陳梓瀚(vczh)
            >>但是一個(gè)團(tuán)隊(duì)使用相同的編譯器是應(yīng)該的
            這也就暗示了C++庫(kù)最方便的復(fù)用形式是源代碼, 而不是二進(jìn)制。


            >>其他語(yǔ)言的Exception都有Message,這個(gè)可是好東西啊……而且catch(...)不能處理基本錯(cuò)誤,譬如說(shuō)access violation,還有divided by zero等等。
            其他語(yǔ)言可以 throw 1212么? 1212怎么message?
            SEH可以處理那2種, 還可以轉(zhuǎn)化為C++ exception。 但是, 非Windows下?

            其他語(yǔ)言是通過(guò)"限制能夠被throw的對(duì)象的類(lèi)型" —— 比如必須繼承自Exception;
            來(lái)達(dá)到使用catch (Exception e)就可以處理所有異常的目的。

            C++沒(méi)有這一限制, 需要自我限制。


            其他語(yǔ)言是通過(guò)某些平臺(tái)相關(guān)的機(jī)制: 比如SEH來(lái)處理access violation;
            或者是通過(guò)損失基礎(chǔ)運(yùn)算的效率: 比如
            T& dereference(T* p) { if (p) return *p; throw nullptr_exception(); }
            unsigned plus(unsigned x, unsigned y)
            {
            if (UINT_MAX-x>y) return x+y;
            throw overflow_exception();
            }
            來(lái)得到這些錯(cuò)誤的異常。

            C++不會(huì)添加這些保姆工作。


            所以, 其實(shí)也不算C++ exception相對(duì)于其他語(yǔ)言的劣勢(shì), 只能算一種權(quán)衡。
            默認(rèn)情況下, 不限制可拋出類(lèi)型, 可以通過(guò)catch (...)來(lái)處理所有。
            如果需要, 可以自我規(guī)定一個(gè)基類(lèi)。

            默認(rèn)情況下, 不檢測(cè)基本運(yùn)算的錯(cuò)誤。
            如果需要, 自己檢測(cè)并拋出。
            2010-06-01 01:30 | OwnWaterloo

            # re: 解讀google C++ code style談對(duì)C++的理解  回復(fù)  更多評(píng)論   

            引用:“當(dāng)程序員沒(méi)有為類(lèi)編寫(xiě)一個(gè)默認(rèn)構(gòu)造函數(shù)的時(shí)候, 編譯器會(huì)自動(dòng)生成一個(gè)默認(rèn)構(gòu)造函數(shù),而這個(gè)編譯器生成的函數(shù)如何實(shí)現(xiàn)(比如如何初始化類(lèi)成員對(duì)象)是不確定的”

            老兄能詳細(xì)解釋一下否?我不明白你這話(huà)里要說(shuō)的意思,能否具體說(shuō)說(shuō)你擔(dān)心的“不確定”?
            2010-06-01 09:54 | Kenny Yuan

            # re: 解讀google C++ code style談對(duì)C++的理解  回復(fù)  更多評(píng)論   

            @Kenny Yuan
            我的意思是編譯器生成的構(gòu)造函數(shù)不知道會(huì)給類(lèi)成員對(duì)象賦什么初值.如果自己寫(xiě)的話(huà),給它們賦一個(gè)明確的初值,這樣在出問(wèn)題的時(shí)候一看,知道這些都是沒(méi)有被初始化過(guò)的.
            2010-06-01 10:29 | 那誰(shuí)

            # re: 解讀google C++ code style談對(duì)C++的理解  回復(fù)  更多評(píng)論   

            @樓主

            明白你說(shuō)的意思了,看來(lái)我們是在“類(lèi)成員對(duì)象”中的“對(duì)象”一詞上的理解不一致了,呵呵

            2010-06-01 11:02 | Kenny Yuan

            # re: 解讀google C++ code style談對(duì)C++的理解  回復(fù)  更多評(píng)論   

            @Kenny Yuan
            哦,怎么說(shuō)?談?wù)勀愕睦斫?
            2010-06-01 11:03 | 那誰(shuí)

            # re: 解讀google C++ code style談對(duì)C++的理解  回復(fù)  更多評(píng)論   

            @那誰(shuí)
            默認(rèn)構(gòu)造函數(shù)的行為是"可預(yù)測(cè)"的。
            就在你文章第1段中提到的書(shū)"inside C++ object model"中就有。
            最關(guān)鍵的一句話(huà): "編譯器合成的構(gòu)造函數(shù), 只為滿(mǎn)足C++的需要, 而不是程序員的需要。"


            所以, 默認(rèn)構(gòu)造函數(shù)的行為是"可預(yù)測(cè)的", "確定的", 即 —— 具有trivial construct語(yǔ)意的member, 不會(huì)被初始化, 而是包含隨機(jī)值。


            關(guān)于隨機(jī)值的兩種處理:
            FILE* f;
            ...
            f = fopen( ... );

            還是
            FILE* f = 0;
            ...
            f = fopen( ... );


            后一種所謂的"規(guī)范寫(xiě)法", 在我看來(lái)完全是多此一舉。
            當(dāng)然, 如果你真的需要這種多余的動(dòng)作:
            struct T {
            ... no constructor
            };

            T v = T(); // 不再是隨機(jī)值。 v中的每個(gè)值都是確定的。
            2010-06-01 17:48 | OwnWaterloo

            # re: 解讀google C++ code style談對(duì)C++的理解  回復(fù)  更多評(píng)論   

            boost::value_intialized<T>(x)
            2010-06-02 12:29 | 空明流轉(zhuǎn)

            # re: 解讀google C++ code style談對(duì)C++的理解  回復(fù)  更多評(píng)論   

            @樓主

            C++標(biāo)準(zhǔn)關(guān)于ctor中成員的初始化順序/值/copy ctor/assign operator等都有詳細(xì)規(guī)定。你說(shuō)的對(duì)象二字,在原句中,無(wú)論從狹義還是廣義上都不成立。但當(dāng)你解釋完之后,我就知道你想要說(shuō)的是哪種情形了(從寫(xiě)法上看是調(diào)用者需要使用trivial ctor)。有什么疑問(wèn)大家都回家看標(biāo)準(zhǔn)吧,我不多寫(xiě)了(樓上有人寫(xiě)了不少了)
            2010-06-02 19:06 | Kenny Yuan

            # re: 解讀google C++ code style談對(duì)C++的理解[未登錄](méi)  回復(fù)  更多評(píng)論   

            @OwnWaterloo
            又一個(gè)技術(shù)流的家伙。c++中難學(xué)難用是出了名的。
            有幾個(gè)人啃過(guò)c++標(biāo)準(zhǔn),幾個(gè)人的代碼量超過(guò)幾萬(wàn)行的?
            軟件開(kāi)發(fā)是一個(gè)工程,一個(gè)大家公認(rèn)的簡(jiǎn)單清晰的代碼規(guī)范,比使用所謂的高級(jí)特性給開(kāi)發(fā)效率帶來(lái)的提升更多。
            2010-06-12 08:39 | dudu

            # re: 解讀google C++ code style談對(duì)C++的理解  回復(fù)  更多評(píng)論   

            @dudu
            >> 一個(gè)大家公認(rèn)的簡(jiǎn)單清晰的代碼規(guī)范

            異常對(duì)于你們不清晰? 怪誰(shuí)? 怪你沒(méi)入"技術(shù)流"?

            并不是大家公認(rèn), 使用異常的語(yǔ)言是越來(lái)越多, 只是你們不求進(jìn)步而已。
            要說(shuō)公認(rèn), 也就是固步自封流公認(rèn)罷了。
            2010-06-12 08:51 | OwnWaterloo

            # re: 解讀google C++ code style談對(duì)C++的理解  回復(fù)  更多評(píng)論   

            路過(guò),學(xué)習(xí)了
            2010-06-12 10:28 | 溪流

            # re: 解讀google C++ code style談對(duì)C++的理解  回復(fù)  更多評(píng)論   

            就想linus說(shuō)的,C++是門(mén)讓人恐慌的語(yǔ)言,而更讓人恐慌的的是一些不專(zhuān)業(yè)的程序員正在使用它,google或許是從大局上考慮,畢竟這么大的一個(gè)公司能完全協(xié)調(diào)的都使用好異常等特性是比較難的,而現(xiàn)在這種激烈競(jìng)爭(zhēng)的環(huán)境下,他們選擇保守,出半點(diǎn)差錯(cuò)不起的啊。。。
            2010-06-26 10:42 | buffer

            # re: 解讀google C++ code style談對(duì)C++的理解  回復(fù)  更多評(píng)論   

            的確,有些c++程序員固步自封,自以為是得太厲害了,抗拒很多現(xiàn)代語(yǔ)言的東西。
            2010-06-29 10:08 | donglongchao

            # re: 解讀google C++ code style談對(duì)C++的理解  回復(fù)  更多評(píng)論   

            看到各位反對(duì)google的理由,感到十分親切,跟我當(dāng)年想得一模一樣。
            成長(zhǎng)總需要過(guò)程,沒(méi)見(jiàn)過(guò)哪個(gè)程序員夸耀自己的當(dāng)年的遠(yuǎn)見(jiàn)卓識(shí),都是在反省自己的很傻很天真。
            2011-03-15 14:04 | dayn9

            # re: 解讀google C++ code style談對(duì)C++的理解  回復(fù)  更多評(píng)論   

            @dayn9
            不要裝,好嗎?有什么話(huà)說(shuō)出來(lái),大家都可以受教~
            2011-03-15 21:32 | 溪流

            # re: 解讀google C++ code style談對(duì)C++的理解  回復(fù)  更多評(píng)論   

            中文社區(qū)果然全是噴子。。。
            2011-08-25 13:09 | lord

            # re: 解讀google C++ code style談對(duì)C++的理解  回復(fù)  更多評(píng)論   

            我覺(jué)得異常也好,rtti,既然用了c++就應(yīng)該是要使用的。既然stl的錯(cuò)誤處理都是用異常實(shí)現(xiàn)的,難道連stl都不用了么?
            確實(shí)c++中有一些語(yǔ)言特性被公認(rèn)標(biāo)記為無(wú)用,例如異常規(guī)范與導(dǎo)出模板,但是異常絕不是其中之一。
            合情合理的使用語(yǔ)言特性才是一個(gè)真正的程序員應(yīng)該做的事情。
            2011-08-28 22:03 | watsonsong

            # re: 解讀google C++ code style談對(duì)C++的理解  回復(fù)  更多評(píng)論   

            mark...
            2011-08-30 13:06 | captivated

            # re: 解讀google C++ code style談對(duì)C++的理解  回復(fù)  更多評(píng)論   

            @OwnWaterloo
            編碼規(guī)范是一種控制質(zhì)量的手段,制定者希望通過(guò)微調(diào)規(guī)范的每個(gè)細(xì)節(jié)讓整個(gè)產(chǎn)品的損益值達(dá)到最優(yōu)化,所以雖然有很多高手能把exception玩的滴水不漏,但作為整個(gè)產(chǎn)品系編碼規(guī)范的制定者,必須考慮到還有其他水平并不那么出色的開(kāi)發(fā)者,另外,不知道你有沒(méi)有仔細(xì)讀過(guò)google列出的這些反對(duì)使用exception的觀點(diǎn),很明顯的是,有些問(wèn)題并不是技術(shù)牛逼就能解決的,很顯然excepion的完美使用過(guò)于繁瑣,而人又是容易犯錯(cuò)的,所以在編譯器或者說(shuō)語(yǔ)言本身沒(méi)辦法提供更智能化更安全糾錯(cuò)機(jī)制的前提下,禁止使用exception也是非常值得理解的。最后,我又仔細(xì)看了你的回復(fù)內(nèi)容,發(fā)現(xiàn)你并沒(méi)有真正理解google的觀點(diǎn),關(guān)于編寫(xiě)異常安全代碼,可以看一下exceptional C++的第二章,然后再來(lái)這里發(fā)言吧。
            2011-09-26 23:24 | stepinto

            # re: 解讀google C++ code style談對(duì)C++的理解  回復(fù)  更多評(píng)論   

            @stepinto
            上面有條回復(fù)正中要害:
            >> 結(jié)論:google禁止異常比較省錢(qián)。

            那么,你們禁止使用(了解)異常(以及其他各種技術(shù))是為了什么呢?
            為了當(dāng)你所說(shuō)的那種
            >> 水平并不那么出色的開(kāi)發(fā)者
            對(duì)嗎? 你就甘愿當(dāng)這種拖后腿的人,是嗎?

            >> 可以看一下exceptional C++的第二章,然后再來(lái)這里發(fā)言吧。
            不好意思,整個(gè)exceptional系列我都看過(guò)好多年了。
            你想得到的與想不到的C++書(shū)籍我都看過(guò)。
            你想得到的與想不到的C++技術(shù)我都玩過(guò)。
            所以我才看不起你們這種 *為自己的無(wú)能找借口* 的人。
            2011-09-26 23:51 | OwnWaterloo

            # re: 解讀google C++ code style談對(duì)C++的理解  回復(fù)  更多評(píng)論   

            @OwnWaterloo
            暈,感覺(jué)是被那本“拒絕借口”給洗腦了。。。。
            2011-09-27 10:57 | stepinto

            # re: 解讀google C++ code style談對(duì)C++的理解  回復(fù)  更多評(píng)論   

            Google并沒(méi)有說(shuō)異常就是不好。使用異常有好處,也有壞處。Google不推薦使用的最大原因是現(xiàn)有代碼使用異常的很少,也就是兼容性的原因。Style Guide里面也承認(rèn)如果重頭開(kāi)始一個(gè)項(xiàng)目,使用異常是利大于弊的。
            2011-10-14 10:06 | Zor X.L.

            # re: 解讀google C++ code style談對(duì)C++的理解  回復(fù)  更多評(píng)論   

            想請(qǐng)問(wèn)一件事
            若果使用異常處理,通常隱含著代碼樹(shù)中會(huì)有非常多的異常類(lèi)的檔案出現(xiàn)
            那么有什么比較有系統(tǒng)的方式維護(hù)這些眾多的異常類(lèi)呢?
            2011-10-23 23:56 | UGP

            # re: 解讀google C++ code style談對(duì)C++的理解  回復(fù)  更多評(píng)論   

            @UGP
            另外補(bǔ)充一篇
            http://chinesetrad.joelonsoftware.com/Articles/Wrong.html
            2011-10-24 14:21 | UGP

            # re: 解讀google C++ code style談對(duì)C++的理解  回復(fù)  更多評(píng)論   

            @UGP
            joel這篇文章足以暴露他思維層次太低。


            即使是在C語(yǔ)言中,對(duì)i+j,同樣不能確定它究竟做了什么。
            完全被優(yōu)化掉了?
            還是上下文中有重復(fù)計(jì)算,此處直接取的結(jié)果?
            但有多少人是真正關(guān)心i+j具體被如何處理,實(shí)現(xiàn)的么?
            絕大多數(shù)情況都不需要。

            那為什么對(duì)C++,就要求了解i+j是具體在干什么呢?
            做出這樣批評(píng)的人,都是 *只懂得C級(jí)別的抽象方式,不懂得C++級(jí)別的抽象方式* 而已。


            對(duì)異常也是如此。
            對(duì)自己熟悉的方式根深蒂固,以至于根本就無(wú)法恰當(dāng)分析其他方式。
            他的批評(píng),比如讓代碼難以理解,熟悉異常的人的眼中完全不可理解。


            而匈牙利更是扇自己嘴巴。
            他要的就是將safe與unsafe字符串通過(guò)某種方式告訴編譯器。
            比如用不同類(lèi)型,限制它們之間的自由轉(zhuǎn)換,轉(zhuǎn)換只能通過(guò)可控制的有限方式。
            然后,讓 *編譯器自動(dòng)地完成這樣的檢測(cè)* ,而不是什么手工肉眼去比。
            2011-10-25 00:51 | OwnWaterloo

            # re: 解讀google C++ code style談對(duì)C++的理解  回復(fù)  更多評(píng)論   

            關(guān)于異常這塊,你沒(méi)有看完http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml#Exceptions 的說(shuō)明

            On their face, the benefits of using exceptions outweigh the costs, especially in new projects. However, for existing code, the introduction of exceptions has implications on all dependent code. If exceptions can be propagated beyond a new project, it also becomes problematic to integrate the new project into existing exception-free code. Because most existing C++ code at Google is not prepared to deal with exceptions, it is comparatively difficult to adopt new code that generates exceptions.

            2013-05-07 17:00 | baibaichen
            久久综合综合久久狠狠狠97色88| 久久99国产一区二区三区| 东京热TOKYO综合久久精品| 久久精品不卡| 狠狠色丁香婷综合久久| 国内精品久久久久影院优 | 国产高潮久久免费观看| 久久久久久久久无码精品亚洲日韩 | 久久99久久无码毛片一区二区| 99久久精品影院老鸭窝| 久久综合给合久久国产免费| 亚洲v国产v天堂a无码久久| 久久久久噜噜噜亚洲熟女综合 | 久久久久亚洲AV片无码下载蜜桃| 中文字幕乱码久久午夜| 香蕉久久av一区二区三区| 无码超乳爆乳中文字幕久久| 亚洲精品无码久久久久去q| 亚洲午夜久久久影院伊人| 亚洲va久久久噜噜噜久久| 人妻少妇久久中文字幕| 久久久久久久97| 人妻无码αv中文字幕久久琪琪布 人妻无码久久一区二区三区免费 人妻无码中文久久久久专区 | 久久精品www人人爽人人| 久久免费精品视频| 久久久久亚洲AV成人网人人软件| 久久夜色撩人精品国产| 亚洲乱码中文字幕久久孕妇黑人| 久久中文骚妇内射| 精品乱码久久久久久夜夜嗨| 日韩久久久久中文字幕人妻| 亚洲中文久久精品无码| 国产精品久久久天天影视| 久久久久亚洲精品天堂久久久久久| 亚洲国产成人久久综合碰| 性欧美大战久久久久久久久| 久久青青草原国产精品免费| 亚洲七七久久精品中文国产| 青青草原精品99久久精品66| 色播久久人人爽人人爽人人片aV| 久久久一本精品99久久精品66 |