@@ -90,40 +90,44 @@ <h2 align="center">Documentation Structure</h2>
90
90
</ dl >
91
91
</ dd >
92
92
93
+ < dt > < a href ="#web "> Web Reference Documentation</ a > </ dt >
94
+
93
95
< dt > < a href ="#footnotes "> Footnotes</ a > </ dt >
94
96
</ dl >
95
97
96
98
< h2 > < a name ="introduction " id ="introduction "> Introduction</ a > </ h2 >
97
99
98
- < p > Boost itself does not require any specific documentation structure. The
99
- C++ Standard, however, has very explicit requirements for the description
100
- of library components (Section 17.3). So for Boost libraries likely to be
101
- proposed for inclusion in the standard, it is highly desirable to structure
102
- documentation in a way that meets the requirements of the the standard.
103
- Doing so eliminates the need to rewrite the documentation for
104
- standardization.</ p >
105
-
106
- < p > Library developers should remember that for a library to be accepted as
107
- part of the C++ Standard Library, the proposal must include full wording.
108
- The committee will not do that work for you.</ p >
109
-
110
- < p > Beyond that, the documentation structure required for the standard is an
111
- effective way to communicate the technical specifications for a library.
112
- Although terse, it is already familiar to many Boost users, and is far more
113
- precise than most ad hoc documentation structures.</ p >
114
-
115
- < p > The following description is for the structure of documentation required
116
- by the standard. Boost libraries should also provided additional
117
- documentation, such as introductory, tutorial, example, and rationale
118
- material.</ p >
100
+ < p > Boost does not require any specific documentation structure.
101
+ However, there are some important considerations that
102
+ influence content and structure. For example, many Boost
103
+ libraries wind up being proposed for inclusion in the C++
104
+ Standard, so writing them initially with text suitable for
105
+ inclusion in the Standard may be helpful. Also, Boost library
106
+ documentation is often accessed via the World Wide Web,
107
+ including via search engines, so context is often important
108
+ for every page. Finally, Boost libraries should provide
109
+ additional documentation, such as introductory, tutorial,
110
+ example, and rationale content. With those things in mind, we
111
+ suggest the following guidelines for Boost library
112
+ documentation.</ p >
119
113
120
114
< h2 > < a name ="standards-conforming " id ="standards-conforming "> Standards
121
115
Conforming</ a > Documentation</ h2 >
122
116
117
+ < p > The documentation structure required for the C++ Standard is
118
+ an effective way to describe the technical specifications for
119
+ a library. Although terse, that format is familiar to many
120
+ Boost users and is far more precise than most ad hoc formats.
121
+ The following description is based upon §17.3 of the
122
+ Standard. (Note that while final Standard proposals must
123
+ include full standardese wording, which the committee will
124
+ not do for you, that level of detail is not expected of Boost
125
+ library documentation.)</ p >
126
+
123
127
< h3 > < a name ="elements " id ="elements "> Document elements</ a > </ h3 >
124
128
125
129
< p > Each document contains the following elements, as applicable< a class =
126
- "footnote " href ="#footnote1 "> (1)</ a > :</ p >
130
+ "footnote " href ="#footnote1 " id =" footnote1-location " > (1)</ a > :</ p >
127
131
128
132
< ul >
129
133
< li > < a href ="#summary "> Summary</ a > </ li >
@@ -197,7 +201,7 @@ <h4><a name="requirements" id="requirements">Requirements</a></h4>
197
201
< p > In some cases the semantic requirements are presented as C++ code. Such
198
202
code is intended as a specification of equivalance of a construct to
199
203
another construct, not necessarily as the way the construct must be
200
- implemented.< a class ="footnote " href ="#footnote2 "> (2)</ a > </ p >
204
+ implemented.< a class ="footnote " href ="#footnote2 " id =" footnote2-location " > (2)</ a > </ p >
201
205
202
206
< h4 > < a name ="detailed-specs " id ="detailed-specs "> Detailed
203
207
specification</ a > </ h4 >
@@ -218,7 +222,7 @@ <h4><a name="detailed-specs" id="detailed-specs">Detailed
218
222
</ ul >
219
223
220
224
< p > Descriptions of class member functions follow the order (as
221
- appropriate)< a class ="footnote " href ="#footnote3 "> (3)</ a > :</ p >
225
+ appropriate)< a class ="footnote " href ="#footnote3 " id =" footnote3-location " > (3)</ a > :</ p >
222
226
223
227
< ul >
224
228
< li > Constructor(s) and destructor</ li >
@@ -236,7 +240,7 @@ <h4><a name="detailed-specs" id="detailed-specs">Detailed
236
240
237
241
< p > Descriptions of function semantics contain the following < a name =
238
242
"function-elements " id ="function-elements "> elements</ a > (as
239
- appropriate)< a class ="footnote " href ="#footnote4 "> (4):</ a > </ p >
243
+ appropriate)< a class ="footnote " href ="#footnote4 " id =" footnote4-location " > (4):</ a > </ p >
240
244
241
245
< dl class ="function-semantics ">
242
246
< dt > < b > < a href ="#requires "> Requires:</ a > </ b > the preconditions for
@@ -390,24 +394,48 @@ <h4><a name="rationale" id="rationale">Rationale</a></h4>
390
394
give users a lot of insight into why a library is designed the way it is.
391
395
More importantly, it can help prevent "fixing" something that wasn't really
392
396
broken as the library matures.</ p >
397
+
398
+ < h2 id ="web "> Web Reference Documentation</ h2 >
399
+
400
+ < p > Boost library documentation is often accessed via the World
401
+ Web. Using search engines, a page deep in the reference
402
+ content could be viewed without any further context.
403
+ Therefore, it is helpful to add extra context, such as the
404
+ following, to each page:</ p >
405
+
406
+ < ul >
407
+ < li > Describe the enclosing namespace or use fully scoped
408
+ identifiers.
409
+ < li > Document required headers for each type or function.
410
+ < li > Link to relevant tutorial information.
411
+ < li > Link to related example code.
412
+ < li > Include the library name.
413
+ < li > Include navigation elements to the beginning of the
414
+ documentation.
415
+ </ ul >
416
+
417
+ < p > It is also useful to consider the effectiveness of a
418
+ description in search engines. Terse or cryptic descriptions
419
+ are less likely to help the curious find a relevant function
420
+ or type.</ p >
393
421
394
422
< h2 > < a name ="footnotes " id ="footnotes "> Footnotes</ a > </ h2 >
395
423
396
424
< dl >
397
- < dt > < a class ="footnote " name ="footnote1 " id =" footnote1 "> (1)</ a > To save
425
+ < dt > < a class ="footnote " id ="footnote1 " href =" # footnote1-location "> (1)</ a > To save
398
426
space, items that do not apply to a clause are omitted. For example, if a
399
427
clause does not specify any requirements, there will be no "Requirements"
400
428
subclause.</ dt >
401
429
402
- < dt > < a class ="footnote " name ="footnote2 " id =" footnote2 "> (2)</ a > Although
430
+ < dt > < a class ="footnote " id ="footnote2 " href =" # footnote2-location "> (2)</ a > Although
403
431
in some cases the code is unambiguously the optimum implementation.</ dt >
404
432
405
- < dt > < a class ="footnote " name ="footnote3 " id =" footnote3 "> (3)</ a > To save
433
+ < dt > < a class ="footnote " id ="footnote3 " href =" # footnote3-location "> (3)</ a > To save
406
434
space, items that do not apply to a class are omitted. For example, if a
407
435
class does not specify any comparison functions, there will be no
408
436
"Comparison functions" subclause.</ dt >
409
437
410
- < dt > < a class ="footnote " name ="footnote4 " id =" footnote4 "> (4)</ a > To save
438
+ < dt > < a class ="footnote " id ="footnote4 " href =" # footnote4-location "> (4)</ a > To save
411
439
space, items that do not apply to a function are omitted. For example, if
412
440
a function does not specify any precondition, there will be no "Requires"
413
441
paragraph.</ dt >
0 commit comments