Boost C++ 函式庫

...世界上最受推崇且設計精良的 C++ 函式庫專案之一。 Herb SutterAndrei AlexandrescuC++ 編碼標準

為 Boost 編寫文件

文件結構

簡介
符合標準的文件
文件元素
摘要
需求
詳細規格
C++ 標準函式庫的參考
C 標準函式庫的參考
其他慣例
型別描述
更多資訊
函式語意元素說明
要求 (Requires)
作用 (Effects)
後置條件 (Postconditions)
回傳 (Returns)
拋出 (Throws)
複雜度 (Complexity)
基本原理 (Rationale)
網路參考文件
註腳

簡介

Boost 並未要求任何特定的文件結構。然而,有一些重要的考量會影響內容和結構。例如,許多 Boost 函式庫最終會被提議納入 C++ 標準,因此一開始就以適合納入標準的文字來撰寫它們可能會有所幫助。此外,Boost 函式庫文件通常透過全球資訊網存取,包括透過搜尋引擎,因此對於每個頁面而言,上下文通常很重要。最後,Boost 函式庫應提供額外的文件,例如簡介、教學、範例和基本原理內容。考量到這些因素,我們建議以下 Boost 函式庫文件的指南。

符合標準的文件

C++ 標準所需的文件結構是描述函式庫技術規格的有效方法。儘管簡潔,但這種格式對於許多 Boost 使用者來說很熟悉,而且比大多數臨時格式更精確。以下描述基於標準的 §17.3。(請注意,雖然最終的標準提案必須包含完整的標準用語,而委員會不會為您執行此操作,但 Boost 函式庫文件不要求達到這種詳細程度。)

文件元素

每個文件都包含以下元素,如適用(1)

摘要

摘要提供類別的概要,並介紹第一層子條款。每個子條款也提供摘要,列出子條款中指定的標頭以及每個標頭中提供的函式庫實體。

標記為「注意(Note(s):)」或「範例(Example(s):)」的段落是資訊性的,其他段落是規範性的。

摘要和詳細規格的呈現順序為

需求

函式庫可以由 C++ 程式擴充。每個條款(如適用)都會描述此類擴充必須滿足的需求。此類擴充通常屬於以下其中一種

介面慣例需求盡可能以一般方式陳述。介面不會陳述「class X 必須定義成員函式 operator++()」,而是要求「對於 class X 的任何物件 x,都會定義 ++x」。也就是說,運算子是否為成員是未指定的。

需求以定義完善的表示式來陳述,這些表示式定義了滿足需求之型別的有效術語。對於每組需求,都有一個表格指定有效表示式及其語意的初始集合。使用需求的任何泛型演算法都會根據其形式型別參數的有效表示式來描述。

範本引數需求有時會以名稱參考。

在某些情況下,語意需求會以 C++ 程式碼呈現。此類程式碼旨在說明結構與另一個結構的等效性,而不一定是該結構必須實作的方式。(2)

詳細規格

每個詳細規格都包含以下元素

類別成員函式的描述依以下順序 (如適用)(3)

函式語意的描述包含以下 元素(如適用)(4):

要求 (Requires): 呼叫函式的前提條件
作用 (Effects): 函式執行的動作
後置條件 (Postconditions): 函式建立的可觀察結果
回傳 (Returns): 函式傳回的值的描述
拋出 (Throws): 函式拋出的任何例外,以及導致例外的條件
複雜度 (Complexity): 函式的時間和/或空間複雜度
基本原理 (Rationale): 函式設計或存在的基本原理

函式庫條款中指定的複雜度要求是上限,提供更好複雜度保證的實作滿足這些要求。

C++ 標準函式庫的參考

C 標準函式庫的參考

其他慣例

這些慣例用於描述實作定義的型別和成員函式。

型別描述

需求子條款可能會描述用於指定範本引數限制的名稱。

更多資訊

函式語意元素說明

函式語意元素描述 以上 直接取自 C++ 標準,而且相當簡潔。以下是每個元素的更詳細說明。

請注意使用 <code> ... </code> 字型標籤來區分實際 C++ 用法和英文散文。

要求 (Requires)

呼叫函式的前提條件,通常表示為述詞。最常見的前提條件是對引數值的要求,通常採用 C++ 表示式的形式。例如,

 
void limit( int * p, int min, int max );
要求 (Requires): p != 0 && min <= max

C++ 語言規則已強制執行的要求(例如引數的型別)不會在「要求 (Requires)」段落中重複。

作用 (Effects)

函式執行的動作,以散文或 C++ 描述。以散文描述通常對實作者的限制較少,但通常不如 C++ 程式碼精確。

如果作用是在其他元素(特別是後置條件回傳拋出)之一中指定,則也不會在作用段落中描述。只有單一描述可確保只有一個規格,從而消除差異的風險。

後置條件 (Postconditions)

函式的可觀察結果,例如變數的值。後置條件通常表示為函式完成後為 true 的述詞,採用 C++ 表示式的形式。例如

 
void make_zero_if_negative( int & x );
後置條件 (Postcondition): x >= 0

回傳 (Returns)

函式傳回的值,通常採用 C++ 表示式的形式。例如

int sum( int x, int y );
回傳 (Returns): x + y

僅指定回傳值;型別已由 C++ 語言規則規定。

拋出 (Throws)

指定拋出的例外型別和導致拋出例外的條件。例如,std::basic_string 類別指定

 
void resize(size_type n, charT c);
拋出 (Throws): 如果 n > max_size() 則拋出 length_error

複雜度 (Complexity)

指定函式時間和/或空間複雜度通常是不理想的,因為這會過度限制實作者,而且難以正確指定。因此,複雜度通常最好留給實作品質問題。

然而,如果符合要求的實作之間在效能上有很大差異,則函式庫元件可能會變得實際上無法移植。容器就是一個很好的例子。在這些情況下,指定複雜度變得值得。

複雜度通常以一般化的 「大 O」符號 指定。

基本原理 (Rationale)

指定函式設計或存在的基本原理通常可以讓使用者深入了解函式庫的設計方式。更重要的是,它可以幫助防止在函式庫成熟時「修復」一些實際上沒有壞掉的東西。

網路參考文件

Boost 函式庫文件通常透過全球資訊網存取。使用搜尋引擎,可能會在沒有任何其他上下文的情況下檢視參考內容中的深層頁面。因此,在每個頁面新增額外的上下文會很有幫助,例如以下內容

考慮描述在搜尋引擎中的有效性也很有用。簡潔或含糊的描述不太可能幫助好奇的人找到相關的函式或型別。

註腳

(1) 為了節省空間,會省略不適用於條款的項目。例如,如果條款未指定任何需求,則不會有「需求」子條款。
(2) 雖然在某些情況下,程式碼明確是最佳實作。
(3) 為了節省空間,會省略不適用於類別的項目。例如,如果類別未指定任何比較函式,則不會有「比較函式」子條款。
(4) 為了節省空間,會省略不適用於函式的項目。例如,如果函式未指定任何前提條件,則不會有「要求 (Requires)」段落。

Valid HTML 4.01 Transitional

修訂2006 年 12 月 4 日

版權所有 © 2001 William E. Kempf

根據 Boost 軟體授權條款 1.0 版發布。(請參閱隨附的檔案 LICENSE_1_0.txt 或副本位於 https://boost.dev.org.tw/LICENSE_1_0.txt)