第一篇：高質(zhì)量編寫(xiě)c c++ 讀書(shū)筆記

質(zhì)量屬性:正確性、健壯性、可靠性、效率、易用性、可讀性（可理解性）、可擴(kuò)展性、可復(fù)用性、兼容性、可移植

頭文件:ifndef/define/endif

頭文件的作用:

*通過(guò)頭文件來(lái)調(diào)用庫(kù)功能。在很多場(chǎng)合，源代碼不便（或不準(zhǔn)）向用戶公布，只要向用戶提供頭文件和二進(jìn)制的庫(kù)即可。用戶只需要按照頭文件中的接口聲明來(lái)調(diào)用庫(kù)功能，而不必關(guān)心接口怎么實(shí)現(xiàn)的。編譯器會(huì)從庫(kù)中提取相應(yīng)的代碼。

*頭文件能加強(qiáng)類(lèi)型安全檢查。如果某個(gè)接口被實(shí)現(xiàn)或被使用時(shí)，其方式與頭文件中的聲明不一致，編譯器就會(huì)指出錯(cuò)誤，這一簡(jiǎn)單的規(guī)則能大大減輕程序員調(diào)試、改錯(cuò)的負(fù)擔(dān)。

如果一個(gè)軟件的頭文件數(shù)目比較多（如超過(guò)十個(gè)），通常應(yīng)將頭文件和 定義文件分別保存于不同的目錄，以便于維護(hù)。

程序的板式:

程序的版式追求清晰、美觀

在每個(gè)類(lèi)聲明之后、每個(gè)函數(shù)定義結(jié)束之后都要加空行。

一行代碼只做一件事情，如只定義一個(gè)變量，或只寫(xiě)一條語(yǔ)句。這樣的代碼容易閱讀，并且方便于寫(xiě)注釋。

長(zhǎng)表達(dá)式要在低優(yōu)先級(jí)操作符處拆分成新行，操作符放在新行之首（以便突出操作符）。拆分出的新行要進(jìn)行適當(dāng)?shù)目s進(jìn)，使排版整齊，語(yǔ)句可讀。

命名規(guī)則:

*標(biāo)識(shí)符最好采用英文單詞或其組合，便于記憶和閱讀。切忌使用漢語(yǔ)拼音來(lái)命名。

*命名規(guī)則盡量與所采用的操作系統(tǒng)或開(kāi)發(fā)工具的風(fēng)格保持一致。

*程序中不要出現(xiàn)僅靠大小寫(xiě)區(qū)分的相似的標(biāo)識(shí)符。

*變量的名字應(yīng)當(dāng)使用“名詞”或者“形容詞＋名詞”。

*全局函數(shù)的名字應(yīng)當(dāng)使用“動(dòng)詞”或者“動(dòng)詞＋名詞”（動(dòng)賓詞組）。類(lèi)的成員函數(shù)應(yīng)當(dāng)只使用“動(dòng)詞”，被省略掉的名詞就是對(duì)象本身。

類(lèi)名和函數(shù)名用大寫(xiě)字母開(kāi)頭的單詞組合而成。

變量和參數(shù)用小寫(xiě)字母開(kāi)頭的單詞組合而成。

常量全用大寫(xiě)的字母，用下劃線分割單詞。

靜態(tài)變量加前綴 s_。

如果不得已需要全局變量，則使全局變量加前綴 g_（表示 global）。

類(lèi)的數(shù)據(jù)成員加前綴 m_（表示 member），這樣可以避免數(shù)據(jù)成員與成員函數(shù)的參數(shù)同名。

為了防止某一軟件庫(kù)中的一些標(biāo)識(shí)符和其它軟件庫(kù)中的沖突，可以為各種標(biāo)識(shí)符加上能反映軟件性質(zhì)的前綴。例如三維圖形標(biāo)準(zhǔn) OpenGL 的所有庫(kù)函數(shù) 均以 gl 開(kāi)頭，所有常量（或宏定義）均以 GL 開(kāi)頭。

常量:

在 C++ 程序中只使用 const 常量而不使用宏常量，即 const 常量完全取代宏常量。

需要對(duì)外公開(kāi)的常量放在頭文件中，不需要對(duì)外公開(kāi)的常量放在定義文件的頭部。

建立在整個(gè)類(lèi)中都恒定的常量應(yīng)該用類(lèi)中的枚舉常量來(lái)實(shí)現(xiàn)。(只能是整數(shù))

函數(shù)設(shè)計(jì):

值傳遞（pass by value）

指針傳遞（pass by pointer）

引用傳遞（pass by reference）

目的參數(shù)放在前面，源參數(shù)放在后面。

如: char *strcpy(char *strDestination, const char *strSource);

第二篇：如何編寫(xiě)高質(zhì)量“軟件需求說(shuō)明書(shū)”.doc

如何編寫(xiě)高質(zhì)量“軟件需求說(shuō)明書(shū)”2003-01-27· · ··天極論壇 2 下一頁(yè)

你的工程應(yīng)該有個(gè)好的起點(diǎn)。一個(gè)小組要帶領(lǐng)客戶進(jìn)入需求啟發(fā)階段而且你要寫(xiě)軟件需求說(shuō)明書(shū)。這份說(shuō)明有些大，但客戶會(huì)很重視，所以說(shuō)明必須得到贊同。

現(xiàn)在你正在設(shè)計(jì)其中的一個(gè)特性，已經(jīng)發(fā)現(xiàn)了需求的一些問(wèn)題。你可以用多種不同的方式解釋需求15；需求9 的說(shuō)明正好與需求21相反，你因該相信哪一個(gè)？需求24非常含糊，你根本不明白它的意思；你不得不花上一個(gè)小時(shí)與2位開(kāi)發(fā)人員討論需求30，只因?yàn)槟銈儗?duì) 其各有各的理解；并且，唯一能夠澄清這些問(wèn)題的客戶沒(méi)有給你們答復(fù)。你被迫破解眾多需求的含義，并且你能預(yù)料到，如果你錯(cuò)了，你要做大量的重復(fù)工作。

許多軟件需求說(shuō)明書(shū)（SRS）寫(xiě)得非常糟糕。任何產(chǎn)品的質(zhì)量需要其原始材料的質(zhì)量保證，糟糕的軟件需求說(shuō)明書(shū)不可能產(chǎn)出優(yōu)秀的軟件。不幸的是，幾乎沒(méi)有開(kāi)發(fā)人員受過(guò)與需求的抽象、分析、文檔、質(zhì)檢有關(guān)的教育。而且，沒(méi)有非常多的好需求可以借鑒學(xué)習(xí)，部分原因是很少有工程可以找到一個(gè)好的借鑒，其 他原因是公司不愿意將其產(chǎn)品說(shuō)明書(shū)放在公共區(qū)域。

這篇文章描述了高質(zhì)量需求敘述和說(shuō)明的幾個(gè)特性（特點(diǎn)）。我們將用這些觀點(diǎn)檢查一些有缺陷的需求，帶著痛楚重新編寫(xiě)。而且我會(huì)談一些如何編寫(xiě)好 的需求的提示。你也許想通過(guò)這些質(zhì)量標(biāo)準(zhǔn)評(píng)估你的工程需求。對(duì)于修訂，也許遲了，但你會(huì)學(xué)到一些有用的東西，并幫助你的小組在下次編寫(xiě)出更好的需求。

不要期望能夠編寫(xiě)出一份能體現(xiàn)需求應(yīng)具備的所有特性的SRS。無(wú)論你怎么細(xì)化、分析、評(píng)論和優(yōu)化需求，都不可能達(dá)到完美。但是，如果你牢記這些特性，你就會(huì)編寫(xiě)出更好的需求，生產(chǎn)出更好的產(chǎn)品。

高質(zhì)量需求敘述的特性

我們?nèi)绾螐囊恍┯袉?wèn)題的需求中分辨出好的軟件需求？這一節(jié)將分別介紹需求敘述應(yīng)體現(xiàn)的6個(gè)特性，下一節(jié)將從整體上介紹SRS文檔應(yīng)具備的特性。判斷每個(gè)需求是否具備應(yīng)有的特性的一種方式是由持有不同觀點(diǎn)的工程資金管理人所作的正規(guī)檢查。另一種有力的方法是在編寫(xiě)代碼前依據(jù)需求編寫(xiě)測(cè)試?yán)?。測(cè)試 例子能夠明確顯現(xiàn)在需求中描述的產(chǎn)品行為（特性），能夠顯現(xiàn)缺陷、冗余和含糊之處。

正確：每個(gè)需求必須精確描述要交付的功能。正確性依據(jù)于需求的來(lái)源，如真實(shí)的客戶或高級(jí)別的系統(tǒng)需求說(shuō)明書(shū)。一個(gè)軟件需求與其對(duì)應(yīng)的系統(tǒng)需求說(shuō)明書(shū)相抵觸是不正確的（當(dāng)然，系統(tǒng)需求說(shuō)明書(shū)本身可能不正確）。

只有用戶的代表能夠決定用戶需求的正確性，這就是為什么在檢查需求時(shí)，要包括他們或他們的代理的關(guān)鍵所在。不包括用戶的需求檢查就會(huì)導(dǎo)致開(kāi)發(fā)人員的：“這是沒(méi)意義的”，“這可能是他們的意思”等眾所周知的猜測(cè)。

可行性：在已知的能力、有限的系統(tǒng)及其環(huán)境中每個(gè)需求必須是可實(shí)現(xiàn)的。為了避免需求的不可行性，在需求分析階段應(yīng)該有一個(gè)開(kāi)發(fā)人員參與，在抽象階段應(yīng)該有市場(chǎng)人員參與。這個(gè)開(kāi)發(fā)人員應(yīng)能檢查在技術(shù)上什么能做什么不能做，哪些需要需要額外的付出或者和其他的權(quán)衡。

必要性：每個(gè)需求應(yīng)載明什么是客戶確實(shí)需要的，什么要順應(yīng)于外部的需求，接口或標(biāo)準(zhǔn)。每個(gè)需求源于你認(rèn)可、具有權(quán)說(shuō)明需求的原始資料，這是考慮 必需的另外情形（譯注，此句翻譯不順，請(qǐng)參照原文：Another way to think of “necessary” is that each requirement originated from a source you recognize as having the authority to specify requirements）。跟蹤每個(gè)需求回溯到出處，如用例，系統(tǒng)需求，規(guī)章，或來(lái)自其他用戶的意見(jiàn)。如果你不能標(biāo)識(shí)出處，可能需求只是個(gè)鍍金的例子，沒(méi)有真正的必須。

優(yōu)先權(quán)：為了表明在一個(gè)詳細(xì)的產(chǎn)品版本中應(yīng)包含哪些要點(diǎn)，需要為每個(gè)需求，特征，或用例分配實(shí)現(xiàn)的優(yōu)先權(quán)?？蛻艋蚱浯矶紤?yīng)有強(qiáng)烈的責(zé)任建立優(yōu) 先權(quán)。如果所有的需求都被視為同等重要，那么由于在開(kāi)發(fā)中，預(yù)算削減，計(jì)劃超時(shí)或組員的離開(kāi)導(dǎo)致新的需求時(shí)，項(xiàng)目經(jīng)理將不能起到作用。優(yōu)先權(quán)的作用是提供給客戶的價(jià)值，實(shí)現(xiàn)的相關(guān)費(fèi)用，實(shí)現(xiàn)相關(guān)聯(lián)的有關(guān)技術(shù)風(fēng)險(xiǎn)。

我是用3種級(jí)別的優(yōu)先權(quán)：高優(yōu)先權(quán)表明需求必須體現(xiàn)在下一個(gè)產(chǎn)品版本中，中優(yōu)先權(quán)表明需求是必須的，但是如果需要可以推遲到晚一些的產(chǎn)品版本中，低優(yōu)先權(quán)表明有它很好，但我們必須認(rèn)識(shí)到如果沒(méi)有充足的時(shí)間或資源，它可以被放棄掉。

明確：需求敘述的讀者應(yīng)只能從其得到唯一的解釋說(shuō)明，同樣，一個(gè)需求的多個(gè)讀者也應(yīng)達(dá)成共識(shí)。自然語(yǔ)言極易導(dǎo)致含糊。要避免使用一些對(duì)于SRS 作者很清楚但對(duì)于讀者不清楚的主觀詞匯，如：用戶友好性，容易，簡(jiǎn)單，快速，有效，幾個(gè)，藝術(shù)級(jí)，改善的，最大，最小等等。每寫(xiě)一個(gè)需要都應(yīng)簡(jiǎn)潔，簡(jiǎn)單，直觀的采用用戶熟知的語(yǔ)言，不要采用計(jì)算機(jī)術(shù)語(yǔ)。檢查需求模糊的有效方式包括需求說(shuō)明書(shū)的正規(guī)檢查，根據(jù)需求寫(xiě)測(cè)試，建立用戶的假想來(lái)說(shuō)明產(chǎn)品某個(gè)特定部 分預(yù)期的特性。

可證實(shí)：看你是否能夠做出測(cè)試計(jì)劃或其他驗(yàn)證方式，如檢查和實(shí)證，來(lái)決定在產(chǎn)品中每個(gè)需求是否正確的實(shí)現(xiàn)。如果需求是不可驗(yàn)證的，決定需求是不 是正確的實(shí)現(xiàn)就成了判斷的事。需求之間不一致，不可行，不明確也能導(dǎo)致不可證實(shí)。任何需求如果說(shuō)產(chǎn)品將要支持什么也是不可證實(shí)的。

高質(zhì)量需求說(shuō)明的特征

一個(gè)完整的SRS不僅是包括長(zhǎng)長(zhǎng)的功能性需求列表，還包括外部接口描述和一些諸如質(zhì)量屬性，期望性能的非功能性需求。下面描述了高質(zhì)量的SRS的一些特性。

完整：不應(yīng)該遺漏要求和必需的信息。完整性也是一個(gè)需求應(yīng)具備的。發(fā)現(xiàn)缺少的信息很難，因?yàn)楦静淮嬖?。在SRS中將需求以分層目錄方式組織，將幫助評(píng)審人員理解功能性描述的結(jié)構(gòu)，使他們很容易指出遺失的東西。

在需求抽象時(shí)，相對(duì)于系統(tǒng)功能，你過(guò)多的注意用戶的業(yè)務(wù)，將導(dǎo)致在需求的全局觀和引進(jìn)不是真正必需的需求上顯得不足。在需求抽象上，應(yīng)用用例方法會(huì)發(fā)揮很好的作用。能夠從不同角度察看需求的圖形分析模型也可以檢查出不完整性。

如果你知道已缺少一些信息，使用TBD（to be determined）標(biāo)準(zhǔn)標(biāo)志可以突出這些缺陷，當(dāng)你在構(gòu)建產(chǎn)品的相關(guān)部分時(shí)，就可以從一個(gè)給定的需求集中解決所有的缺陷。

一致性：一致性需求就是不要于其他的軟件需求或高級(jí)別的系統(tǒng)（商業(yè)）需求發(fā)生沖突。需求中的不一致必須在開(kāi)發(fā)開(kāi)始前得到解決。只有經(jīng)過(guò)調(diào)研才能確定哪些是正確的。修改需求時(shí)一定要謹(jǐn)慎，如果只審定修改的部分，沒(méi)有審定于修改相關(guān)的部分，就可能導(dǎo)致不一致性。

可修改性：當(dāng)每個(gè)需求的要求修改了或維護(hù)其歷史更改時(shí)，你必須能夠?qū)彾⊿RS。也就是說(shuō)每個(gè)需求必須相對(duì)于其他需求有其單獨(dú)的標(biāo)示和分開(kāi)的說(shuō)明，便于清晰的查閱。通過(guò)良好的組織可以使需求易于修改，如：將相關(guān)的需求分組，建立目錄表，索引，以及前后參考（照）。

可追蹤：你應(yīng)能將一個(gè)軟件與其原始材料相對(duì)應(yīng)，如高級(jí)系統(tǒng)需求，用例，用戶的提議等。也能夠?qū)④浖枨笈c設(shè)計(jì)元素，源代碼，用于構(gòu)造實(shí)現(xiàn)和驗(yàn)證需求的測(cè)試相對(duì)應(yīng)?？勺粉櫟男枨髴?yīng)該具有獨(dú)立標(biāo)示，細(xì)密和結(jié)構(gòu)化的編寫(xiě)，不應(yīng)過(guò)大，不應(yīng)是敘述性的文字和公告式的列表。

需求質(zhì)量的評(píng)審

這些有關(guān)需求質(zhì)量的特性的描述在理論上都是非常好的，但一個(gè)好的需求到底是個(gè)什么樣子的呢？為了體現(xiàn)得更切合實(shí)際，我們做個(gè)小練習(xí)。下面有幾個(gè) 從實(shí)際的工程選出的需求，依據(jù)上面的質(zhì)量標(biāo)準(zhǔn)，評(píng)估每個(gè)需求，看看有什么問(wèn)題，然后用更好的方式重寫(xiě)。我將對(duì)每個(gè)例子都提出自己的分析和改進(jìn)的建議。也歡 迎你提出不同的見(jiàn)解。我所占優(yōu)的只是我知道每個(gè)需求的出處。因?yàn)槟阄叶疾皇钦嬲目蛻簦覀冎荒懿聹y(cè)每個(gè)需求的意圖。

例1．“產(chǎn)品應(yīng)在不少于每60秒的正常周期內(nèi)提供狀態(tài)信息”

這個(gè)需求是不完整的：狀態(tài)信息是什么，如何顯示給用戶。這個(gè)需 求有幾處含糊。我們?cè)谡務(wù)摦a(chǎn)品的哪部分？狀態(tài)信息間隔真的假定為不少于60秒？，甚者每10年顯示一條新的狀態(tài)信息也可以？也許它的意圖是消息間隔不應(yīng)超 過(guò)60秒，那么1毫秒是不是太短？“每”這個(gè)詞導(dǎo)致了不確定性。問(wèn)題的后果，就是需求的不可證實(shí)。

彌補(bǔ)缺陷，重寫(xiě)需求的一種方法：

1、狀態(tài)信息

1．1后臺(tái)任務(wù)管理器因該以誤差上下不超過(guò)10秒的60秒間隔，在用戶界面的指定位置顯示狀態(tài)信息

1．2如果后臺(tái)進(jìn)程處理正常，那么應(yīng)該顯示任務(wù)已完成的百分?jǐn)?shù)/比

1．3任務(wù)完成時(shí)，應(yīng)顯示相關(guān)的信息

1．4后臺(tái)任務(wù)出錯(cuò)應(yīng)該顯示錯(cuò)誤信息

為了分別測(cè)試和追蹤，我將其分成了多個(gè)需求。如果將幾個(gè)需求串接在一節(jié)中，在構(gòu)造和測(cè)試時(shí)就很容易漏掉一個(gè)。

例2．“產(chǎn)品應(yīng)瞬間在顯示和隱藏不可打印字符間切換”

計(jì)算機(jī)在瞬間不能做任何事，所以這個(gè)需求不切實(shí)可行。它的不完整性 表現(xiàn)在沒(méi)有聲明觸發(fā)狀態(tài)切換的條件。軟件要在某些條件下更改自己？或者用戶為了模仿更改要做一些動(dòng)作？而且，在文檔中改變顯示的范圍是多大：選中的文本，整個(gè)的文檔，或其他的？這也是個(gè)模糊的問(wèn)題。不可打印字符合隱藏字符一樣嗎？或者是一些屬性標(biāo)志或一些控制字符？問(wèn)題的后果，就是需求的不可證實(shí)。

象這樣編寫(xiě)需求也許更好一些：“用戶能夠在一個(gè)由特定觸發(fā)條件激活處于編輯的文檔中在顯示和隱藏所有HTML標(biāo)記間切換”?，F(xiàn)在就很清楚，不可 打印字符是HTML標(biāo)記。由于沒(méi)有定義觸發(fā)條件，需求對(duì)設(shè)計(jì)沒(méi)有約束力。只有設(shè)計(jì)人員選定了觸發(fā)條件后，你才能編寫(xiě)測(cè)試驗(yàn)證觸發(fā)的正確操作。

例3．“HTML分析器可以產(chǎn)生HTML標(biāo)記錯(cuò)誤報(bào)告，幫助HTML入門(mén)者快速解決錯(cuò)誤”。單詞“快速”使其模糊，沒(méi)

有加進(jìn)錯(cuò)誤報(bào)告的定義也是其部完整。我不知道，你怎么驗(yàn)證這個(gè)需求。找一個(gè)自稱為HTML的入門(mén)者，看看能不能根據(jù)錯(cuò)誤報(bào)告快速解決錯(cuò)誤？

試試這個(gè)：“HTML分析器可以產(chǎn)生一個(gè)錯(cuò)誤報(bào)告，錯(cuò)誤報(bào)告包含有在被分析文件中出錯(cuò)的HTML文本和行號(hào)以及錯(cuò)誤的描述。如果沒(méi)有錯(cuò)誤，就不 會(huì)產(chǎn)生錯(cuò)誤報(bào)告”。現(xiàn)在我們知道了，什么會(huì)被加到出錯(cuò)報(bào)告中，但是出錯(cuò)報(bào)告是個(gè)什么樣子，則留由設(shè)計(jì)人員決定。我們還指定了一個(gè)例外：如果沒(méi)有發(fā)現(xiàn)錯(cuò)誤，不產(chǎn)生錯(cuò)誤報(bào)告。

例4．“如果可能，主管號(hào)碼應(yīng)通過(guò)聯(lián)機(jī)校驗(yàn)，而不是通過(guò)主全體主管號(hào)碼列表校驗(yàn)”。真感到絕望，什么是“如果可能”：如果技術(shù)上可行？如果主全 體主管號(hào)碼列表可以聯(lián)機(jī)獲得？要避免象“應(yīng)該”的這類(lèi)不確切的詞?？蛻羰切枰@個(gè)功能性還是不需要。我曾看過(guò)一些需求說(shuō)明書(shū)，采用諸如：應(yīng)，將，應(yīng)該/

將 要等一些詞描述優(yōu)先級(jí)的細(xì)微差別。但我更喜歡用“應(yīng)”清楚的說(shuō)明需求的意圖，指明優(yōu)先級(jí)。這是修改后的：系統(tǒng)應(yīng)校驗(yàn)輸入的主管號(hào)碼而不通過(guò)聯(lián)機(jī)的主全體主 官號(hào)碼列表。如果在列表中沒(méi)有發(fā)現(xiàn)主管號(hào)碼，將會(huì)顯示一條錯(cuò)誤信息，也不接受指令。

在理解各個(gè)已完成的糟糕需求上，開(kāi)發(fā)人員將會(huì)遇到的難題是：開(kāi)發(fā)人員與客戶將會(huì)在審核需求，未達(dá)成共識(shí)前發(fā)生激烈的爭(zhēng)論。詳細(xì)檢查大的需求文檔 不是一件輕松的事情。我清楚有人做過(guò)，而且他們花在檢查上的每一分鐘都是值得的。相對(duì)于開(kāi)發(fā)階段和用戶的抱怨電話，在這個(gè)階段修補(bǔ)缺陷是便宜的，編寫(xiě)質(zhì)量需求的方針

編寫(xiě)優(yōu)秀的需求是沒(méi)有公式化的方法的。這需要大量的經(jīng)驗(yàn)，要從你在過(guò)去的文檔中發(fā)現(xiàn)的問(wèn)題學(xué)習(xí)。請(qǐng)?jiān)诮M織軟件需求文檔時(shí)，嚴(yán)格遵從這些方針。

句子和段落要短。采用主動(dòng)語(yǔ)氣。使用正確的語(yǔ)法，拼寫(xiě)，標(biāo)點(diǎn)。使用術(shù)語(yǔ)，要保持一致性，并在術(shù)語(yǔ)表或數(shù)據(jù)字典中定義它們

要看需求是否被有效的定義，可以以開(kāi)發(fā)人員的觀點(diǎn)看看。在內(nèi)心將“當(dāng)你們做完了找我”這句加到文檔尾部，看看能不能是你緊張起來(lái)。換句話說(shuō)，你 是否需要SRS的編寫(xiě)者的額外解釋幫助開(kāi)發(fā)人員很好的理解需求，以便于設(shè)計(jì)和實(shí)現(xiàn)？如果是的話，在繼續(xù)工作前，需求還需要細(xì)化。

需求編寫(xiě)者還要努力正確地把握細(xì)化程度。要避免包含多個(gè)需求的長(zhǎng)的敘述段落。有幫助的提示是編寫(xiě)?yīng)毩⒌目蓽y(cè)試的需求。如果你認(rèn)為一小部分測(cè)試可以驗(yàn)證一個(gè)需求的正確，那么它已經(jīng)正確的細(xì)化了。如果你預(yù)想到多種不同類(lèi)的測(cè)試，幾個(gè)需求可能已擠到了一起，需要拆分開(kāi)。

密切關(guān)注多個(gè)需求合成了單個(gè)需求。一個(gè)需求中的連接詞“和”/“或”建議幾個(gè)需求合并。不要在一個(gè)需求中使用“和”/“或”。

通篇文檔細(xì)節(jié)上要保持一致。我曾看見(jiàn)過(guò)多個(gè)需求說(shuō)明書(shū)前后不一致。如：“對(duì)于紅色合法的顏色代碼應(yīng)是R”及“對(duì)于綠色合法的顏色代碼應(yīng)是G”就有可以以分散的需求分離開(kāi)，而“產(chǎn)品應(yīng)能對(duì)來(lái)自語(yǔ)音編輯指示做出反應(yīng)”應(yīng)作為一個(gè)子系統(tǒng)，不應(yīng)作為單個(gè)的功能性需求。

避免在SRS中過(guò)多的申述需求。在多處包含相同的需求可以使文檔更易于閱讀，但也會(huì)給文檔的維護(hù)增加困難。文檔的多份文本要在同一時(shí)間內(nèi)全部更新，避免不一致性。

如果你遵從了這些方針，你能夠盡早地經(jīng)常正式或非正式的審查需求，這些需求對(duì)于產(chǎn)品的構(gòu)造，系統(tǒng)測(cè)試以及最后的客戶滿意，都會(huì)成為好的奠基石。并且要記住，沒(méi)有高質(zhì)量的需求，軟件就象一盒巧克力，你永遠(yuǎn)不知道你會(huì)得到什么。

第三篇：如何編寫(xiě)高質(zhì)量的“軟件需求說(shuō)明書(shū)”

如何編寫(xiě)高質(zhì)量“軟件需求說(shuō)明書(shū)”

你的工程應(yīng)該有個(gè)好的起點(diǎn)。一個(gè)小組要帶領(lǐng)客戶進(jìn)入需求啟發(fā)階段而且你要寫(xiě)軟件需求說(shuō)明書(shū)。這份說(shuō)明有些大，但客戶會(huì)很重視，所以說(shuō)明必須得到贊同。

現(xiàn)在你正在設(shè)計(jì)其中的一個(gè)特性，已經(jīng)發(fā)現(xiàn)了需求的一些問(wèn)題。你可以用多種不同的方式解釋需求15；需求9 的說(shuō)明正好與需求21相反，你因該相信哪一個(gè)？需求24非常含糊，你根本不明白它的意思；你不得不花上一個(gè)小時(shí)與2位開(kāi)發(fā)人員討論需求30，只因?yàn)槟銈儗?duì)其各有各的理解；并且，唯一能夠澄清這些問(wèn)題的客戶沒(méi)有給你們答復(fù)。你被迫破解眾多需求的含義，并且你能預(yù)料到，如果你錯(cuò)了，你要做大量的重復(fù)工作。

許多軟件需求說(shuō)明書(shū)（SRS）寫(xiě)得非常糟糕。任何產(chǎn)品的質(zhì)量需要其原始材料的質(zhì)量保證，糟糕的軟件需求說(shuō)明書(shū)不可能產(chǎn)出優(yōu)秀的軟件。不幸的是，幾乎沒(méi)有開(kāi)發(fā)人員受過(guò)與需求的抽象、分析、文檔、質(zhì)檢有關(guān)的教育。而且，沒(méi)有非常多的好需求可以借鑒學(xué)習(xí)，部分原因是很少有工程可以找到一個(gè)好的借鑒，其他原因是公司不愿意將其產(chǎn)品說(shuō)明書(shū)放在公共區(qū)域。

這篇文章描述了高質(zhì)量需求敘述和說(shuō)明的幾個(gè)特性（特點(diǎn)）。我們將用這些觀點(diǎn)檢查一些有缺陷的需求，帶著痛楚重新編寫(xiě)。而且我會(huì)談一些如何編寫(xiě)好的需求的提示。你也許想通過(guò)這些質(zhì)量標(biāo)準(zhǔn)評(píng)估你的工程需求。對(duì)于修訂，也許遲了，但你會(huì)學(xué)到一些有用的東西，并幫助你的小組在下次編寫(xiě)出更好的需求。

不要期望能夠編寫(xiě)出一份能體現(xiàn)需求應(yīng)具備的所有特性的SRS。無(wú)論你怎么細(xì)化、分析、評(píng)論和優(yōu)化需求，都不可能達(dá)到完美。但是，如果你牢記這些特性，你就會(huì)編寫(xiě)出更好的需求，生產(chǎn)出更好的產(chǎn)品。

高質(zhì)量需求敘述的特性

我們?nèi)绾螐囊恍┯袉?wèn)題的需求中分辨出好的軟件需求？這一節(jié)將分別介紹需求敘述應(yīng)體現(xiàn)的6個(gè)特性，下一節(jié)將從整體上介紹SRS文檔應(yīng)具備的特性。判斷每個(gè)需求是否具備應(yīng)有的特性的一種方式是由持有不同觀點(diǎn)的工程資金管理人所作的正規(guī)檢查。另一種有力的方法是在編寫(xiě)代碼前依據(jù)需求編寫(xiě)測(cè)試?yán)印y(cè)試?yán)幽軌蛎鞔_顯現(xiàn)在需求中描述的產(chǎn)品行為（特性），能夠顯現(xiàn)缺陷、冗余和含糊之處。

正確：每個(gè)需求必須精確描述要交付的功能。正確性依據(jù)于需求的來(lái)源，如真實(shí)的客戶或高級(jí)別的系統(tǒng)需求說(shuō)明書(shū)。一個(gè)軟件需求與其對(duì)應(yīng)的系統(tǒng)需求說(shuō)明書(shū)相抵觸是不正確的（當(dāng)然，系統(tǒng)需求說(shuō)明書(shū)本身可能不正確）。

只有用戶的代表能夠決定用戶需求的正確性，這就是為什么在檢查需求時(shí)，要包括他們或他們的代理的關(guān)鍵所在。不包括用戶的需求檢查就會(huì)導(dǎo)致開(kāi)發(fā)人員的：“這是沒(méi)意義的”，“這可能是他們的意思”等眾所周知的猜測(cè)。

可行性：在已知的能力、有限的系統(tǒng)及其環(huán)境中每個(gè)需求必須是可實(shí)現(xiàn)的。為了避免需求的不可行性，在需求分析階段應(yīng)該有一個(gè)開(kāi)發(fā)人員參與，在抽象階段應(yīng)該有市場(chǎng)人員參與。這個(gè)開(kāi)發(fā)人員應(yīng)能檢查在技術(shù)上什么能做什么不能做，哪些需要需要額外的付出或者和其他的權(quán)衡。

必要性：每個(gè)需求應(yīng)載明什么是客戶確實(shí)需要的，什么要順應(yīng)于外部的需求，接口或標(biāo)準(zhǔn)。每個(gè)需求源于你認(rèn)可、具有權(quán)說(shuō)明需求的原始資料，這是考慮必需的另外情形（譯注，此句翻譯不順，請(qǐng)參照原文：Another way to think of “necessary” is that each requirement originated from a source you recognize as having the authority to specify requirements）。跟蹤每個(gè)需求回溯到出處，如用例，系統(tǒng)需求，規(guī)章，或來(lái)自其他用戶的意見(jiàn)。如果你不能標(biāo)識(shí)出處，可能需求只是個(gè)鍍金的例子，沒(méi)有真正的必須。

優(yōu)先權(quán)：為了表明在一個(gè)詳細(xì)的產(chǎn)品版本中應(yīng)包含哪些要點(diǎn)，需要為每個(gè)需求，特征，或用例分配實(shí)現(xiàn)的優(yōu)先權(quán)?？蛻艋蚱浯矶紤?yīng)有強(qiáng)烈的責(zé)任建立優(yōu)先權(quán)。如果所有的需求都被視為同等重要，那么由于在開(kāi)發(fā)中，預(yù)算削減，計(jì)劃超時(shí)或組員的離開(kāi)導(dǎo)致新的需求時(shí)，項(xiàng)目經(jīng)理將不能起到作用。優(yōu)先權(quán)的作用是提供給客戶的價(jià)值，實(shí)現(xiàn)的相關(guān)費(fèi)用，實(shí)現(xiàn)相關(guān)聯(lián)的有關(guān)技術(shù)風(fēng)險(xiǎn)。

我是用3種級(jí)別的優(yōu)先權(quán)：高優(yōu)先權(quán)表明需求必須體現(xiàn)在下一個(gè)產(chǎn)品版本中，中優(yōu)先權(quán)表明需求是必須的，但是如果需要可以推遲到晚一些的產(chǎn)品版本中，低優(yōu)先權(quán)表明有它很好，但我們必須認(rèn)識(shí)到如果沒(méi)有充足的時(shí)間或資源，它可以被放棄掉。

明確：需求敘述的讀者應(yīng)只能從其得到唯一的解釋說(shuō)明，同樣，一個(gè)需求的多個(gè)讀者也應(yīng)達(dá)成共識(shí)。自然語(yǔ)言極易導(dǎo)致含糊。要避免使用一些對(duì)于SRS作者很清楚但對(duì)于讀者不清楚的主觀詞匯，如：用戶友好性，容易，簡(jiǎn)單，快速，有效，幾個(gè)，藝術(shù)級(jí)，改善的，最大，最小等等。每寫(xiě)一個(gè)需要都應(yīng)簡(jiǎn)潔，簡(jiǎn)單，直觀的采用用戶熟知的語(yǔ)言，不要采用計(jì)算機(jī)術(shù)語(yǔ)。檢查需求模糊的有效方式包括需求說(shuō)明書(shū)的正規(guī)檢查，根據(jù)需求寫(xiě)測(cè)試，建立用戶的假想來(lái)說(shuō)明產(chǎn)品某個(gè)特定部分預(yù)期的特性。

可證實(shí)：看你是否能夠做出測(cè)試計(jì)劃或其他驗(yàn)證方式，如檢查和實(shí)證，來(lái)決定在產(chǎn)品中每個(gè)需求是否正確的實(shí)現(xiàn)。如果需求是不可驗(yàn)證的，決定需求是不是正確的實(shí)現(xiàn)就成了判斷的事。需求之間不一致，不可行，不明確也能導(dǎo)致不可證實(shí)。任何需求如果說(shuō)產(chǎn)品將要支持什么也是不可證實(shí)的。

高質(zhì)量需求說(shuō)明的特征

一個(gè)完整的SRS不僅是包括長(zhǎng)長(zhǎng)的功能性需求列表，還包括外部接口描述和一些諸如質(zhì)量屬性，期望性能的非功能性需求。下面描述了高質(zhì)量的SRS的一些特性。

完整：不應(yīng)該遺漏要求和必需的信息。完整性也是一個(gè)需求應(yīng)具備的。發(fā)現(xiàn)缺少的信息很難，因?yàn)楦静淮嬖?。在SRS中將需求以分層目錄方式組織，將幫助評(píng)審人員理解功能性描述的結(jié)構(gòu)，使他們很容易指出遺失的東西。

在需求抽象時(shí)，相對(duì)于系統(tǒng)功能，你過(guò)多的注意用戶的業(yè)務(wù)，將導(dǎo)致在需求的全局觀和引進(jìn)不是真正必需的需求上顯得不足。在需求抽象上，應(yīng)用用例方法會(huì)發(fā)揮很好的作用。能夠從不同角度察看需求的圖形分析模型也可以檢查出不完整性。

如果你知道已缺少一些信息，使用TBD（to be determined）標(biāo)準(zhǔn)標(biāo)志可以突出這些缺陷，當(dāng)你在構(gòu)建產(chǎn)品的相關(guān)部分時(shí)，就可以從一個(gè)給定的需求集中解決所有的缺陷。

一致性：一致性需求就是不要于其他的軟件需求或高級(jí)別的系統(tǒng)（商業(yè)）需求發(fā)生沖突。需求中的不一致必須在開(kāi)發(fā)開(kāi)始前得到解決。只有經(jīng)過(guò)調(diào)研才能確定哪些是正確的。修改需求時(shí)一定要謹(jǐn)慎，如果只審定修改的部分，沒(méi)有審定于修改相關(guān)的部分，就可能導(dǎo)致不一致性。

可修改性：當(dāng)每個(gè)需求的要求修改了或維護(hù)其歷史更改時(shí)，你必須能夠?qū)彾⊿RS。也就是說(shuō)每個(gè)需求必須相對(duì)于其他需求有其單獨(dú)的標(biāo)示和分開(kāi)的說(shuō)明，便于清晰的查閱。通過(guò)良好的組織可以使需求易于修改，如：將相關(guān)的需求分組，建立目錄表，索引，以及前后參考（照）。

可追蹤：你應(yīng)能將一個(gè)軟件與其原始材料相對(duì)應(yīng)，如高級(jí)系統(tǒng)需求，用例，用戶的提議等。也能夠?qū)④浖枨笈c設(shè)計(jì)元素，源代碼，用于構(gòu)造實(shí)現(xiàn)和驗(yàn)證需求的測(cè)試相對(duì)應(yīng)。可追蹤的需求應(yīng)該具有獨(dú)立標(biāo)示，細(xì)密和結(jié)構(gòu)化的編寫(xiě)，不應(yīng)過(guò)大，不應(yīng)是敘述性的文字和公告式的列表。

需求質(zhì)量的評(píng)審

這些有關(guān)需求質(zhì)量的特性的描述在理論上都是非常好的，但一個(gè)好的需求到底是個(gè)什么樣子的呢？為了體現(xiàn)得更切合實(shí)際，我們做個(gè)小練習(xí)。下面有幾個(gè)從實(shí)際的工程選出的需求，依據(jù)上面的質(zhì)量標(biāo)準(zhǔn)，評(píng)估每個(gè)需求，看看有什么問(wèn)題，然后用更好的方式重寫(xiě)。我將對(duì)每個(gè)例子都提出自己的分析和改進(jìn)的建議。也歡迎你提出不同的見(jiàn)解。我所占優(yōu)的只是我知道每個(gè)需求的出處。因?yàn)槟阄叶疾皇钦嬲目蛻?，我們只能猜測(cè)每個(gè)需求的意圖。

例1．“產(chǎn)品應(yīng)在不少于每60秒的正常周期內(nèi)提供狀態(tài)信息”

這個(gè)需求是不完整的：狀態(tài)信息是什么，如何顯示給用戶。這個(gè)需求有幾處含糊。我們?cè)谡務(wù)摦a(chǎn)品的哪部分？狀態(tài)信息間隔真的假定為不少于60秒？，甚者每10年顯示一條新的狀態(tài)信息也可以？也許它的意圖是消息間隔不應(yīng)超過(guò)60秒，那么1毫秒是不是太短？“每”這個(gè)詞導(dǎo)致了不確定性。問(wèn)題的后果，就是需求的不可證實(shí)。

彌補(bǔ)缺陷，重寫(xiě)需求的一種方法：

1、狀態(tài)信息

1．1后臺(tái)任務(wù)管理器因該以誤差上下不超過(guò)10秒的60秒間隔，在用戶界面的指定位置顯示狀態(tài)信息

1．2如果后臺(tái)進(jìn)程處理正常，那么應(yīng)該顯示任務(wù)已完成的百分?jǐn)?shù)/比

1．3任務(wù)完成時(shí)，應(yīng)顯示相關(guān)的信息

1．4后臺(tái)任務(wù)出錯(cuò)應(yīng)該顯示錯(cuò)誤信息

為了分別測(cè)試和追蹤，我將其分成了多個(gè)需求。如果將幾個(gè)需求串接在一節(jié)中，在構(gòu)造和測(cè)試時(shí)就很容易漏掉一個(gè)。

例2．“產(chǎn)品應(yīng)瞬間在顯示和隱藏不可打印字符間切換”

計(jì)算機(jī)在瞬間不能做任何事，所以這個(gè)需求不切實(shí)可行。它的不完整性表現(xiàn)在沒(méi)有聲明觸發(fā)狀態(tài)切換的條件。軟件要在某些條件下更改自己？或者用戶為了模仿更改要做一些動(dòng)作？而且，在文檔中改變顯示的范圍是多大：選中的文本，整個(gè)的文檔，或其他的？這也是個(gè)模糊的問(wèn)題。不可打印字符合隱藏字符一樣嗎？或者是一些屬性標(biāo)志或一些控制字符？問(wèn)題的后果，就是需求的不可證實(shí)。

象這樣編寫(xiě)需求也許更好一些：“用戶能夠在一個(gè)由特定觸發(fā)條件激活處于編輯的文檔中在顯示和隱藏所有HTML標(biāo)記間切換”?，F(xiàn)在就很清楚，不可打印字符是HTML標(biāo)記。由于沒(méi)有定義觸發(fā)條件，需求對(duì)設(shè)計(jì)沒(méi)有約束力。只有設(shè)計(jì)人員選定了觸發(fā)條件后，你才能編寫(xiě)測(cè)試驗(yàn)證觸發(fā)的正確操作。

例3．“HTML分析器可以產(chǎn)生HTML標(biāo)記錯(cuò)誤報(bào)告，幫助HTML入門(mén)者快速解決錯(cuò)誤”。單詞“快速”使其模糊，沒(méi)

有加進(jìn)錯(cuò)誤報(bào)告的定義也是其部完整。我不知道，你怎么驗(yàn)證這個(gè)需求。找一個(gè)自稱為HTML的入門(mén)者，看看能不能根據(jù)錯(cuò)誤報(bào)告快速解決錯(cuò)誤？

試試這個(gè)：“HTML分析器可以產(chǎn)生一個(gè)錯(cuò)誤報(bào)告，錯(cuò)誤報(bào)告包含有在被分析文件中出錯(cuò)的HTML文本和行號(hào)以及錯(cuò)誤的描述。如果沒(méi)有錯(cuò)誤，就不會(huì)產(chǎn)生錯(cuò)誤報(bào)告”?，F(xiàn)在我們知道了，什么會(huì)被加到出錯(cuò)報(bào)告中，但是出錯(cuò)報(bào)告是個(gè)什么樣子，則留由設(shè)計(jì)人員決定。我們還指定了一個(gè)例外：如果沒(méi)有發(fā)現(xiàn)錯(cuò)誤，不產(chǎn)生錯(cuò)誤報(bào)告。

例4．“如果可能，主管號(hào)碼應(yīng)通過(guò)聯(lián)機(jī)校驗(yàn)，而不是通過(guò)主全體主管號(hào)碼列表校驗(yàn)”。真感到絕望，什么是“如果可能”：如果技術(shù)上可行？如果主全體主管號(hào)碼列表可以聯(lián)機(jī)獲得？要避免象“應(yīng)該”的這類(lèi)不確切的詞?？蛻羰切枰@個(gè)功能性還是不需要。我曾看過(guò)一些需求說(shuō)明書(shū)，采用諸如：應(yīng)，將，應(yīng)該/將要等一些詞描述優(yōu)先級(jí)的細(xì)微差別。但我更喜歡用“應(yīng)”清楚的說(shuō)明需求的意圖，指明優(yōu)先級(jí)。這是修改后的：系統(tǒng)應(yīng)校驗(yàn)輸入的主管號(hào)碼而不通過(guò)聯(lián)機(jī)的主全體主官號(hào)碼列表。如果在列表中沒(méi)有發(fā)現(xiàn)主管號(hào)碼，將會(huì)顯示一條錯(cuò)誤信息，也不接受指令。

在理解各個(gè)已完成的糟糕需求上，開(kāi)發(fā)人員將會(huì)遇到的難題是：開(kāi)發(fā)人員與客戶將會(huì)在審核需求，未達(dá)成共識(shí)前發(fā)生激烈的爭(zhēng)論。詳細(xì)檢查大的需求文檔不是一件輕松的事情。我清楚有人做過(guò)，而且他們花在檢查上的每一分鐘都是值得的。相對(duì)于開(kāi)發(fā)階段和用戶的抱怨電話，在這個(gè)階段修補(bǔ)缺陷是便宜的，編寫(xiě)質(zhì)量需求的方針

編寫(xiě)優(yōu)秀的需求是沒(méi)有公式化的方法的。這需要大量的經(jīng)驗(yàn)，要從你在過(guò)去的文檔中發(fā)現(xiàn)的問(wèn)題學(xué)習(xí)。請(qǐng)?jiān)诮M織軟件需求文檔時(shí)，嚴(yán)格遵從這些方針。

句子和段落要短。采用主動(dòng)語(yǔ)氣。使用正確的語(yǔ)法，拼寫(xiě)，標(biāo)點(diǎn)。使用術(shù)語(yǔ)，要保持一致性，并在術(shù)語(yǔ)表或數(shù)據(jù)字典中定義它們

要看需求是否被有效的定義，可以以開(kāi)發(fā)人員的觀點(diǎn)看看。在內(nèi)心將“當(dāng)你們做完了找我”這句加到文檔尾部，看看能不能是你緊張起來(lái)。換句話說(shuō)，你是否需要SRS的編寫(xiě)者的額外解釋幫助開(kāi)發(fā)人員很好的理解需求，以便于設(shè)計(jì)和實(shí)現(xiàn)？如果是的話，在繼續(xù)工作前，需求還需要細(xì)化。

需求編寫(xiě)者還要努力正確地把握細(xì)化程度。要避免包含多個(gè)需求的長(zhǎng)的敘述段落。有幫助的提示是編寫(xiě)?yīng)毩⒌目蓽y(cè)試的需求。如果你認(rèn)為一小部分測(cè)試可以驗(yàn)證一個(gè)需求的正確，那么它已經(jīng)正確的細(xì)化了。如果你預(yù)想到多種不同類(lèi)的測(cè)試，幾個(gè)需求可能已擠到了一起，需要拆分開(kāi)。

密切關(guān)注多個(gè)需求合成了單個(gè)需求。一個(gè)需求中的連接詞“和”/“或”建議幾個(gè)需求合并。不要在一個(gè)需求中使用“和”/“或”。

通篇文檔細(xì)節(jié)上要保持一致。我曾看見(jiàn)過(guò)多個(gè)需求說(shuō)明書(shū)前后不一致。如：“對(duì)于紅色合法的顏色代碼應(yīng)是R”及“對(duì)于綠色合法的顏色代碼應(yīng)是G”就有可以以分散的需求分離開(kāi)，而“產(chǎn)品應(yīng)能對(duì)來(lái)自語(yǔ)音編輯指示做出反應(yīng)”應(yīng)作為一個(gè)子系統(tǒng)，不應(yīng)作為單個(gè)的功能性需求。

避免在SRS中過(guò)多的申述需求。在多處包含相同的需求可以使文檔更易于閱讀，但也會(huì)給文檔的維護(hù)增加困難。文檔的多份文本要在同一時(shí)間內(nèi)全部更新，避免不一致性。

如果你遵從了這些方針，你能夠盡早地經(jīng)常正式或非正式的審查需求，這些需求對(duì)于產(chǎn)品的構(gòu)造，系統(tǒng)測(cè)試以及最后的客戶滿意，都會(huì)成為好的奠基石。并且要記住，沒(méi)有高質(zhì)量的需求，軟件就象一盒巧克力，你永遠(yuǎn)不知道你會(huì)得到什么。

第四篇：CC++的一些面試基本題

標(biāo)題: C/C++的一些面試基本題

發(fā)信站: 兵馬俑BBS(Wed Jun 16 15:00:14 2010), 本站(bbs.xjtu.edu.cn)

下面是自己面試時(shí)或是聽(tīng)別人說(shuō)的一些C/C++面試基本題，都是語(yǔ)言細(xì)節(jié)和一些基本功，準(zhǔn)備找工作的同學(xué)是可以看看。至于算法方面的，我面試過(guò)的公司都沒(méi)有問(wèn)什么有深度的東西（總是問(wèn)我排序，堆棧方面的）。關(guān)于算法，我個(gè)人推薦一本書(shū)，algorithms in c（C算法）,我覺(jué)得這本書(shū)寫(xiě)的很好，很值得看（我現(xiàn)在就在看），如果能掌握了這本書(shū)的話，面試算法問(wèn)題就不大了。我知道很多人更喜歡Introduction to algorithms(算法導(dǎo)論）這本書(shū)，這本書(shū)我買(mǎi)了一年多，慚愧，看了一半都不到，習(xí)題寫(xiě)得代碼也不多。不過(guò)我個(gè)人更喜歡algorithms in c這本書(shū)，感覺(jué)它更適合我。

下面就是那些題目了，答案基本上我檢驗(yàn)過(guò)，應(yīng)該錯(cuò)誤不多。

1.求下面函數(shù)的返回值（騰訊，阿里巴巴今年筆試都有）

int func(int x){

int countx = 0;

while(x){

countx++;

x = x &(xb))/ 2

13.如何打印出當(dāng)前源文件的文件名以及源文件的當(dāng)前行號(hào)？

答案：

cout << __FILE__;

cout<<__LINE__;

__FILE__和__LINE__是系統(tǒng)預(yù)定義宏，這種宏并不是在某個(gè)文件中定義的，而是由編譯器定義的。

14.main 主函數(shù)執(zhí)行完畢后，是否可能會(huì)再執(zhí)行一段代碼，給出說(shuō)明？

答案：可以，可以用_onexit 注冊(cè)一個(gè)函數(shù)，它會(huì)在main 之后執(zhí)行。

15.如何判斷一段程序是由C 編譯程序還是由C++編譯程序編譯的？

答案：

#ifdef __cplusplus

cout<<“c++”;

#else

cout<<“c”;

#endif

16.下面程序的輸出結(jié)果是什么啊?

#define SQR(X)X*X

int main(int argc, char* argv[]){

int a = 10;

int k = 2;

int m = 1;

a /= SQR(k+m)/SQR(k+m);

printf(“%dn”,a);

return 0;

}

答案： 1

17，const在一個(gè)函數(shù)中的4個(gè)位置的不同用法（面試我時(shí)我沒(méi)有答上這個(gè)題，汗）主要是要理解const函數(shù)，不能改變對(duì)象。否則編譯會(huì)報(bào)錯(cuò)。

18.寫(xiě)出運(yùn)行結(jié)果:

union V {

struct X {

unsigned char s1:2;

unsigned char s2:3;

unsigned char s3:3;

} x;

unsigned char c;

} v;

v.c = 100;

printf(“%d”, v.x.s2);

}

答案： 1

19.用C++寫(xiě)個(gè)程序，如何判斷一個(gè)操作系統(tǒng)是16位還是32位的？不能用sizeof()函數(shù) A1:

16位的系統(tǒng)下，int i = 65536;

cout << i;// 輸出0；

int i = 65535;

cout << i;// 輸出-1；

32位的系統(tǒng)下，int i = 65536;

cout << i;// 輸出65536；

int i = 65535;

cout << i;// 輸出65535；

A2:

int a = ~0;

if(a>65536){

cout<<“32 bit”<

}

else{

cout<<“16 bit”<

}

20.在不用第三方參數(shù)的情況下，交換兩個(gè)參數(shù)的值

方法1：

i=i+j;

j=i-j;

i=i-j;

方法二：

i^=j;

j^=i;

i^=j;

方法三：

// 用加減實(shí)現(xiàn)，而且不會(huì)溢出

a = a+b-(b=a)

21.寫(xiě)出輸出結(jié)果

typedef union {

int a_int1;

double a_double;

int a_int2;

} a;

typedef struct {

a a1;

char y;

} b;

struct {

double c_double;

b b1;

a a2;

} c;

printf(“%dn”, sizeof(c));

答：有人說(shuō)在VC下答案是32，我是linux系統(tǒng)，沒(méi)法測(cè)試VC，但我知道在gcc下32位機(jī)默認(rèn)的對(duì)齊是4（#pragma pack(4)），所以答案是28.22.試編寫(xiě)函數(shù)判斷計(jì)算機(jī)的字節(jié)存儲(chǔ)順序是開(kāi)序(little endian)還是降序(bigendian)答:

bool IsBigendian(){

unsigned short usData = 0x1122;

unsigned char*pucData =(unsigned char*)&usData;

return(*pucData == 0x22);

}

23.int id[sizeof(unsigned long)];這個(gè)對(duì)嗎？為什么??

答:對(duì)，這個(gè) sizeof是編譯時(shí)運(yùn)算符，編譯時(shí)就確定了，可以看成和機(jī)器有關(guān)的常量。

24.找錯(cuò)

void test1(){

char string[10];

char* str1 = “0123456789”;

strcpy(string, str1);

}

答：數(shù)組越界。

25.分別給出bool，int，float，指針變量 與“零值”比較的 if 語(yǔ)句（假設(shè)變量名為var）答案：

bool型變量：if(!var)

int型變量： if(var==0)

float型變量：

const float EPSINON = 0.00001;

if((x >=-EPSINON)&&(x <= EPSINON)

指針變量：if(var==NULL)

26.請(qǐng)寫(xiě)一個(gè)C函數(shù)，若處理器是Big_endian的，則返回0;若是Little_endian的，則返回1 答：和22題一樣，不過(guò)這里是另外一個(gè)方法。

nt checkCPU()

{

{

union w

{

int a;

char b;

} c;

c.a = 1;

return(c.b == 1);

}

}

27.多態(tài)類(lèi)中的虛函數(shù)表是Compile-Time，還是Run-Time時(shí)建立的（此題我沒(méi)有答上）? 答：是在編譯時(shí)建立的。但在運(yùn)行時(shí)刻才能知道究竟事調(diào)用那個(gè)函數(shù)。

28.寫(xiě)一個(gè)函數(shù)，判斷一個(gè)int型的整數(shù)是否是2的冪，即是否可以表示成2^X的形式（不可以用循環(huán)）

bool IsTwoPower(int s){

return(s > 0)&&((s &(s-1))==0);//如果是2的冪的話，在二進(jìn)制表示中只能有1個(gè)1 }

第五篇：黑馬程序員C語(yǔ)言教程： CC++培訓(xùn)專家-編寫(xiě)高效C語(yǔ)言的四大絕招

傳智播客C/C++培訓(xùn)專家：編寫(xiě)高效C語(yǔ)言的四大絕招

C語(yǔ)言是很多程序猿的入門(mén)語(yǔ)言，而且C語(yǔ)言也是一門(mén)用不過(guò)時(shí)的語(yǔ)言。編寫(xiě)高效簡(jiǎn)潔的C語(yǔ)言代碼，是許多軟件工程師追求的目標(biāo)。今天傳智播客C/C++培訓(xùn)專家針對(duì)編程工作中的一些體會(huì)和經(jīng)驗(yàn)給大家做相關(guān)的闡述。

第一招：以空間換時(shí)間

計(jì)算機(jī)程序中最大的矛盾是空間和時(shí)間的矛盾，那么，從這個(gè)角度出發(fā)逆向思維來(lái)考慮程序的效率問(wèn)題，我們就有了解決問(wèn)題的第1招--以空間換時(shí)間。比如說(shuō)字符串的賦值： 方法A：通常的辦法 #define LEN 32 char string1 [LEN];memset(string1, 0, LEN);strcpy(string1, “This is a example！”);方法B：

const char string2[LEN] =“This is a example!”;char * cp;cp = string2;

從上面的例子可以看出，A和B的效率是不能比的。在同樣的存儲(chǔ)空間下，B直接使用指針就可以操作了，而A需要調(diào)用兩個(gè)字符函數(shù)才能完成。B的缺點(diǎn)在于靈活性沒(méi)有A好。在需要頻繁更改一個(gè)字符串內(nèi)容的時(shí)候，A具有更好的靈活性；如果采用方法B，則需要預(yù)存許多字符串，雖然占用了大量的內(nèi)存，但是獲得了程序執(zhí)行的高效率。

第二招：數(shù)學(xué)方法解決問(wèn)題

現(xiàn)在我們演繹高效C語(yǔ)言編寫(xiě)的第二招--采用數(shù)學(xué)方法來(lái)解決問(wèn)題。數(shù)學(xué)是計(jì)算機(jī)之母，沒(méi)有數(shù)學(xué)的依據(jù)和基礎(chǔ)，就沒(méi)有計(jì)算機(jī)的發(fā)展，所以在編寫(xiě)程序的時(shí)候，采用一些數(shù)學(xué)方法會(huì)對(duì)程序的執(zhí)行效率有數(shù)量級(jí)的提高。舉例如下，求 1~100的和。方法C： int I , j;for(I = 1;I<=100;I ++）{ j += I;} 方法D int I;I =(100 *(1+100))/ 2；

這個(gè)例子是我印象最深的一個(gè)數(shù)學(xué)用例，是我的計(jì)算機(jī)啟蒙老師考我的。當(dāng)時(shí)我只有小學(xué)三年級(jí)，可惜我當(dāng)時(shí)不知道用公式 N×（N+1）

/ 2 來(lái)解決這個(gè)問(wèn)題。方法E循環(huán)了100次才解決問(wèn)題，也就是說(shuō)最少用了100個(gè)賦值，100個(gè)判斷，200個(gè)加法（I和j）；而方法F僅僅用了1個(gè)加法，1 次乘法，1次除法。效果自然不言而喻。所以，現(xiàn)在我在編程序的時(shí)候，更多的是動(dòng)腦筋找規(guī)律，最大限度地發(fā)揮數(shù)學(xué)的威力來(lái)提高程序運(yùn)行的效率。

第三招：使用位操作

實(shí)現(xiàn)高效的C語(yǔ)言編寫(xiě)的第三招——使用位操作。減少除法和取模的運(yùn)算。在計(jì)算機(jī)程序中數(shù)據(jù)的位是可以操作的最小數(shù)據(jù)單位，理論上可以用“位運(yùn)算”來(lái)完成所有的運(yùn)算和操作。一般的位操作是用來(lái)控制硬件的，或者做數(shù)據(jù)變換使用，但是，靈活的位操作可以有效地提高程序運(yùn)行的效率。舉例如下： 方法E int I,J;I = 257 /8;J = 456 % 32;方法F int I,J;I = 257 >>3;J = 456-(456 >> 4 << 4);在字面上好像F比E麻煩了好多，但是，仔細(xì)查看產(chǎn)生的匯編代碼就會(huì)明白，方法E調(diào)用了基本的取模函數(shù)和除法函數(shù)，既有函數(shù)調(diào)用，還有很多匯編代碼和寄存器參與運(yùn)算；而方法F則僅僅是幾句相關(guān)的匯編，代碼更簡(jiǎn)潔，效率更高。當(dāng)然，由于編譯器的不同，可能效率的差距不大，但是，以我目前遇到的MS C ,ARM C 來(lái)看，效率的差距還是不小。相關(guān)匯編代碼就不在這里列舉了。

運(yùn)用這招需要注意的是，因?yàn)镃PU的不同而產(chǎn)生的問(wèn)題。比如說(shuō)，在PC上用這招編寫(xiě)的程序，并在PC上調(diào)試通過(guò)，在移植到一個(gè)16位機(jī)平臺(tái)上的時(shí)候，可能會(huì)產(chǎn)生代碼隱患。所以只有在一定技術(shù)進(jìn)階的基礎(chǔ)下才可以使用這招。用移位實(shí)現(xiàn)乘除法運(yùn)算

a=a*4;

b=b/4;

可以改為：

a=a<<2;

b=b>>2;

說(shuō)明：

除2 = 右移1位 乘2 = 左移1位

除4 = 右移2位 乘4 = 左移2位

除8 = 右移3位 乘8 = 左移3位

......通常如果需要乘以或除以2的n次方，都可以用移位的方法代替。大部分的C編譯器,用移位的方法得到代碼比調(diào)用乘除法子程序生成的代碼效率高。

第四招：匯編嵌入

高效C語(yǔ)言編程的必殺技，第四招——嵌入?yún)R編?！霸谑煜R編語(yǔ)言的人眼里，C語(yǔ)言編寫(xiě)的程序都是垃圾”。這種說(shuō)法雖然偏激了一些，但是卻有它的道理。匯編語(yǔ)言是效率最高的計(jì)算機(jī)語(yǔ)言，但是，不可能靠著它來(lái)寫(xiě)一個(gè)操作系統(tǒng)吧?所以，為了獲得程序的高效率，我們只好采用變通的方法--嵌入?yún)R編，混合編程。舉例如下，將數(shù)組一賦值給數(shù)組二,要求每一字節(jié)都相符。char string1[1024],string2[1024];方法G int i;for(i =0;i<1024;i++)*(string2 + i)= *(string1 + i)方法H #ifdef _PC_ int I;for(I =0;I<1024;I++)*(string2 + I)= *(string1 + I);#else #ifdef _ARM_ __asm

{ MOV R0,string1 MOV R1,string2 MOV R2,#0 loop: LDMIA R0!, [R3-R11] STMIA R1!, [R3-R11] ADD R2,R2,#8 CMP R2, #400 BNE loop } #endif 方法G是最常見(jiàn)的方法，使用了1024次循環(huán)；方法H則根據(jù)平臺(tái)不同做了區(qū)分，在ARM平臺(tái)下，用嵌入?yún)R編僅用128次循環(huán)就完成了同樣的操作。這里有朋友會(huì)說(shuō)，為什么不用標(biāo)準(zhǔn)的內(nèi)存拷貝函數(shù)呢?這是因?yàn)樵谠磾?shù)據(jù)里可能含有數(shù)據(jù)為0的字節(jié)，這樣的話，標(biāo)準(zhǔn)庫(kù)函數(shù)會(huì)提前結(jié)束而不會(huì)完成我們要求的操作。這個(gè)例程典型應(yīng)用于LCD數(shù)據(jù)的拷貝過(guò)程。根據(jù)不同的CPU，熟練使用相應(yīng)的嵌入?yún)R編，可以大大提高程序執(zhí)行的效率。

雖然是必殺技，但是如果輕易使用會(huì)付出慘重的代價(jià)。這是因?yàn)?，使用了嵌入?yún)R編，便限制了程序的可移植性，使程序在不同平臺(tái)移植的過(guò)程中，臥虎藏龍，險(xiǎn)象環(huán)生！同時(shí)該招數(shù)也與現(xiàn)代軟件工程的思想相違背，只有在迫不得已的情況下才可以采用。

今天分享到這里，大家有遇到什么問(wèn)題可以向“傳智播客C/C++培訓(xùn)專家”留言哦！