這是現(xiàn)代C ++，C ++ 17，C ++ 14和C ++ 11的一套核心指南，考慮了未來的增強(qiáng)功能和ISO技術(shù)規(guī)范（TS）。 目的是幫助C ++程序員編寫更簡單，更高效，更易維護(hù)的代碼。

簡介摘要：

• 適用讀者群
• 宗旨
• 非主要目標(biāo)
• 規(guī)范
• 文檔結(jié)構(gòu)
• 主要內(nèi)容

使用讀者群

適用于所有C++編程者以及C語言編程

宗旨

本文檔的目的是幫助開發(fā)人員采用現(xiàn)代C ++（C ++ 17，C ++ 14和C ++ 11），并在代碼庫中實現(xiàn)更統(tǒng)一的風(fēng)格。
我們不會妄圖這些規(guī)則中的每一個都可以有效地應(yīng)用于每個代碼庫。 升級舊系統(tǒng)很難。 但是，我們確實認(rèn)為使用規(guī)則的程序比不使用規(guī)則的程序更不容易出錯且更易于維護(hù)。 通常，規(guī)則也會導(dǎo)致更快/更容易的初始開發(fā)。 據(jù)我們所知，這些規(guī)則導(dǎo)致代碼的表現(xiàn)與舊的，更傳統(tǒng)的技術(shù)一樣好或更好; 它們意味著遵循零開銷原則（“你不使用什么，你不付錢”或“當(dāng)你適當(dāng)?shù)厥褂贸橄髾C(jī)制時，你至少獲得了良好的性能，就像你用較低的手寫代碼一樣 級別語言構(gòu)造“）。 考慮這些規(guī)則對新代碼的理想，在處理舊代碼時利用的機(jī)會，并嘗試盡可能接近這些理想。 記得：

Note

花點時間了解指南規(guī)則對你的程序?qū)a(chǎn)生深遠(yuǎn)影響

這些指南是根據(jù)“超集子集”原則(Stroustrup05)設(shè)計的。 它們不是簡單地定義要使用的C ++子集（用于可靠性，安全性，性能等）。 相反，他們強(qiáng)烈建議使用一些簡單的"extensions"(library components，這些擴(kuò)展使得C ++中容易出錯的最容易出現(xiàn)的特性變得冗余，從而可以禁止它們（在我們的規(guī)則集中）。

規(guī)則強(qiáng)調(diào)靜態(tài)類型安全和資源安全。 出于這個原因，他們強(qiáng)調(diào)范圍檢查的可能性，避免解除引用nullptr，避免懸空指針，以及系統(tǒng)使用異常（通過RAII）。 部分是為了實現(xiàn)這一目標(biāo)，部分是為了最大限度地減少模糊代碼作為錯誤的來源，規(guī)則還強(qiáng)調(diào)簡單性和隱藏在指定良好的接口背后的必要復(fù)雜性。

許多規(guī)則都是規(guī)定性的。 我們對簡單地說 "don't do that!"的規(guī)則感到不安！ 沒有提供替代方案。 其中一個結(jié)果是，某些規(guī)則只能通過啟發(fā)式方法來支持，而不是通過精確和機(jī)械可驗證的檢查。 其他規(guī)則闡明了一般原則。 對于這些更一般的規(guī)則，更詳細(xì)和具體的規(guī)則提供部分檢查。

這些指南解決了C ++的核心及其用途。 我們希望大多數(shù)大型組織，特定應(yīng)用領(lǐng)域甚至大型項目都需要進(jìn)一步的規(guī)則，可能還需要進(jìn)一步的限制，以及進(jìn)一步的圖書館支持。 例如， hard-real-time程序員通常不能自由使用免費存儲（動態(tài)內(nèi)存），并且會限制他們選擇的庫。 我們鼓勵制定更具體的規(guī)則作為這些核心準(zhǔn)則的附錄。 構(gòu)建理想的小型基礎(chǔ)庫并使用它，而不是降低編程水平以獲得美化的匯編代碼。

這些規(guī)則旨在逐步采用.
一些規(guī)則旨在增加各種形式的安全性，而其他規(guī)則旨在減少事故發(fā)生的可能性，許多規(guī)則都是這樣做的。 旨在預(yù)防事故的指導(dǎo)方針通常禁止完全合法的C ++。 然而，當(dāng)有兩種表達(dá)想法的方式，一種表現(xiàn)出共同的錯誤來源而另一種卻沒有，我們試圖引導(dǎo)程序員走向后者。

非主要目標(biāo)

一般規(guī)則不是最小的或者其交集， 特別是，一般規(guī)則可以很簡單，但不可執(zhí)行； 此外，通常很難理解一般規(guī)則的含義。 更專業(yè)的規(guī)則通常更容易理解和執(zhí)行，但如果沒有一般規(guī)則，它們只是一長串的特殊情況。 我們提供旨在幫助新手的規(guī)則以及支持專家使用的規(guī)則。 一些規(guī)則可以完全實施，但其他規(guī)則基于啟發(fā)式。
這些規(guī)則并不意味著像書本一樣連續(xù)閱讀。 您可以使用鏈接瀏覽它們。 但是，它們的主要用途是成為工具的目標(biāo)。 也就是說，工具會查找違規(guī)行為，并且該工具會返回違反規(guī)則的鏈接。 然后，規(guī)則提供了理由，違規(guī)的潛在后果的示例以及建議的補(bǔ)救措施。

這些指南并非旨在替代C ++的教程處理。 如果您需要針對某些特定經(jīng)驗水平的教程，請參閱參考資料.

這不是如何將舊的C ++代碼轉(zhuǎn)換為更現(xiàn)代的代碼的指南。 它旨在以具體的方式闡明新代碼的想法。 但是，請參閱the modernization section,一些可能的現(xiàn)代化/恢復(fù)/升級方法。 重要的是，規(guī)則支持逐步采用：一次完全轉(zhuǎn)換大型代碼庫通常是不可行的。

這些指南并不意味著在每種語言技術(shù)細(xì)節(jié)上都是完整或準(zhǔn)確的。 有關(guān)語言定義問題的最終結(jié)論，包括一般規(guī)則和每個功能的每個例外，請參閱ISO C ++標(biāo)準(zhǔn)。

這些規(guī)則并不是為了強(qiáng)迫您在C ++的貧困子集中編寫。 它們 著重并不意味著定義一個類似Java的C ++子集。 它們并不意味著定義單一的 one true C++語言。 我們重視表現(xiàn)力和不妥協(xié)的表現(xiàn)。

規(guī)則不是價值中立的。 它們旨在使代碼比大多數(shù)現(xiàn)有C ++代碼更簡單，更正確/更安全，而不會降低性能。 它們旨在抑制與錯誤，虛假復(fù)雜性和糟糕性能相關(guān)的完全有效的C ++代碼。

規(guī)則并不完美。 通過禁止在特定情況下有用的東西，規(guī)則可能會造成傷害。 規(guī)則可能會因為未能禁止在特定情況下出現(xiàn)嚴(yán)重錯誤的內(nèi)容而造成傷害。 規(guī)則可以通過有歧義，模糊，不可執(zhí)行或通過啟用問題的每個解決方案來做很多傷害。 完全不符合 "do no harm" 標(biāo)準(zhǔn)是不可能的。 相反，我們的目標(biāo)是不那么雄心勃勃："Do the most good for most programmers"；如果你不能遵守規(guī)則，反對它，忽略它，但不要把它淡化到毫無意義。 否則，建議改進(jìn)。

規(guī)范

對于大型代碼庫，沒有強(qiáng)制執(zhí)行的規(guī)則是不可管理的。所有規(guī)則的強(qiáng)制執(zhí)行只能針對一小部分弱規(guī)則或特定的用戶社區(qū)。

• 但是我們需要很多規(guī)則，而且我們需要每個人都可以使用的規(guī)則。

• 但是不同的人有不同的需求。

• 但是人們不喜歡閱讀很多規(guī)則。

• 但人們不記得很多規(guī)則。
  因此，我們需要特例來滿足各種需求。

• 但任意子集導(dǎo)致混亂。
  我們需要能夠幫助很多人的指南，使代碼更加統(tǒng)一，并強(qiáng)烈鼓勵人們對代碼進(jìn)行現(xiàn)代化。 我們希望鼓勵最佳實踐，而不是將所有實踐留給個人選擇和管理壓力。 理想的是使用所有規(guī)則; 這給了我們最大的好處。
  這加起來有很多困境。 我們嘗試使用工具解決這些問題。 每個規(guī)則都有一個執(zhí)行部分，列出了強(qiáng)制執(zhí)行的想法。 可以通過代碼審查，靜態(tài)分析，編譯器或運行時檢查來執(zhí)行強(qiáng)制執(zhí)行。 在可能的情況下，我們更喜歡“機(jī)械”檢查（humans are slow, inaccurate, and bore easily）和靜態(tài)檢查。 在沒有替代方案的情況下，很少建議運行時檢查; 我們不想介紹"distributed fat"。 在適當(dāng)?shù)那闆r下，我們使用相關(guān)規(guī)則組(called "profiles").的名稱標(biāo)記規(guī)則(in the Enforcement sections）。 規(guī)則可以是多個配置文件的一部分，也可以不是。 首先，我們有一些與常見需求（desires, ideals)相對應(yīng)的配置文件：

• type: 沒有類型違規(guī)(reinterpreting a T as a U through casts, + + unions, or varargs)

• bounds: 沒有邊界違規(guī) (accessing beyond the range of an array)

• lifetime: 沒有內(nèi)存泄露 (failing to delete or multiple delete) and no access to invalid objects (dereferencing nullptr, using a dangling reference).
  這些配置文件旨在供工具使用，但也可以作為人類讀者的幫助。 我們不會將執(zhí)行部分中的評論限制在我們知道如何執(zhí)行的內(nèi)容中; 一些評論只是希望可能激發(fā)一些工具制造者。
  實現(xiàn)這些規(guī)則的工具應(yīng)遵循以下語法來明確禁止規(guī)則：

  [[gsl::suppress(tag)]]
  

其中“tag”是執(zhí)行規(guī)則出現(xiàn)的項目的錨名稱(e.g., for C.134 it is "Rh-public"),是規(guī)則組規(guī)則的名稱("type", "bounds", or "lifetime"),或配置文件中的特定規(guī)則(type.4, or bounds.2)。

文檔結(jié)構(gòu)

每條規(guī)則（指南，建議）可以有幾個部分：

• The rule itself -- e.g., no naked new
• A rule reference number -- e.g., C.7 (the 7th rule related to classes). Since the major sections are not inherently ordered, we use letters as the first part of a rule reference "number". We leave gaps in the numbering to minimize "disruption" when we add or remove rules.
• Reasons(rationales) -- because programmers find it hard to follow rules they don't understand
• Examples -- because rules are hard to understand in the abstract; can be positive or negative
• Alternatives -- for "don't do this" rules
• Exceptions -- we prefer simple general rules. However, many rules apply widely, but not universally, so exceptions must be listed
• Enforcement -- ideas about how the rule might be checked "mechanically"
• See alsos -- references to related rules and/or further discussion (in this document or elsewhere)
• Notes (comments) -- something that needs saying that doesn't fit the other classifications
• Discussion -- references to more extensive rationale and/or examples placed outside the main lists of rules
  有些規(guī)則難以機(jī)械檢查，但它們都符合專家程序員可以毫不費力地發(fā)現(xiàn)許多違規(guī)行為的最低標(biāo)準(zhǔn)。 我們希望“機(jī)械”工具能夠隨著時間的推移而改進(jìn)，以接近這樣的專家程序員注意到的內(nèi)容。 此外，我們假設(shè)規(guī)則將隨著時間的推移而得到改進(jìn)，以使其更加精確和可檢查。
  規(guī)則旨在簡單，而不是仔細(xì)地措辭，以提及每個替代和特殊情況。 此類信息可在備選段落和討論部分中找到。 如果您不理解規(guī)則或不同意規(guī)則，請訪問其討論。 如果您認(rèn)為討論缺失或不完整，請輸入一個問題，解釋您的疑慮以及可能的相應(yīng)PR。
  這不是語言手冊。 它旨在對技術(shù)細(xì)節(jié)或現(xiàn)有代碼指南提供有用而非完整的準(zhǔn)確性。 推薦信息來源可在參考文獻(xiàn)中找到。