53 lines
2.0 KiB
Plaintext
53 lines
2.0 KiB
Plaintext
|
|
The approach I've been using for a given header is to recursively do each
|
|
of the "bits" headers which make up the standard header. So, e.g., while
|
|
there are five headers making up <algorithm>, three of them were already
|
|
documented in the course of doing other headers.
|
|
|
|
"Untouched" means I've deliberately skipped it for various reasons, or
|
|
haven't gotten to it yet. It /will/ be done (by somebody, eventually.)
|
|
|
|
|
|
Area Still needs to be doxygen-documented
|
|
-----------------------------------------------------------
|
|
|
|
c17 FINISHED (Nothing in Clause 17 "exists" in terms of code.)
|
|
c18 <limits>, Note A
|
|
c19 Note A
|
|
c20 rel_ops (should they be doc'd?), Note A
|
|
c21 Untouched, Note B
|
|
c22 Untouched
|
|
c23 See doxygroups.cc and Note B.
|
|
stl_alloc.h, stl_uninitialized.h remain from the common files.
|
|
c24 Untouched
|
|
c25 stl_tempbuf.h (small), stl_algo.h (big)
|
|
c26 <complex>, <valarray>, stl_numeric.h[26.4], Note A
|
|
c27 Untouched
|
|
|
|
backward/ Not scanned by doxygen. Should it be?
|
|
|
|
ext/ Untouched
|
|
|
|
__gnu_cxx Extensions such as verbose_terminate_handler are documented
|
|
but do not appear in output, since the __gnu_cxx namespace is
|
|
itself undocumented. Should it be? Eeeeeeehhh...
|
|
|
|
[1.3.5] "implementation-defined behavior: behavior ... that depends
|
|
on the implementation *and that each implementation shall
|
|
document*." [my emphasis] Not all implementation choices
|
|
have been thus described; doxygen is not necessarily the
|
|
appropriate place for such descriptions, either.
|
|
|
|
-----------------------------------------------------------
|
|
|
|
NOTES:
|
|
|
|
A) So far I have not tried to document any of the <c*> headers. So entities
|
|
such as atexit() are undocumented throughout the library.
|
|
|
|
B) Huge chunks of containers and strings are described in common "Tables"
|
|
in the standard. How to reproduce this information?
|
|
|
|
|
|
vim:ts=4:et:
|