mirror of git://gcc.gnu.org/git/gcc.git
				
				
				
			
		
			
				
	
	
		
			71 lines
		
	
	
		
			3.0 KiB
		
	
	
	
		
			Plaintext
		
	
	
	
			
		
		
	
	
			71 lines
		
	
	
		
			3.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 four 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.)
 | |
| 
 | |
| If you document an area and need to skip (for whatever reason) a non-trivial
 | |
| entity (i.e., one that should be documented), go ahead and add the comment
 | |
| markup, and use the homegrown @doctodo tag.  See include/bits/stl_iterator.h
 | |
| for examples of this.  Doing so will at least cause doxygen to consider the
 | |
| entitiy as documented and include it in the output.  It will also add the
 | |
| entity to the generated TODO page.
 | |
| 
 | |
| 
 | |
|  Area           Still needs to be doxygen-documented
 | |
| -----------------------------------------------------------
 | |
| 
 | |
| c17             FINISHED (Nothing in Clause 17 "exists" in terms of code.)
 | |
| c18             FINISHED, Note A
 | |
| c19             Note A
 | |
| c20             Note A
 | |
| c21             Public functions basic_string done, Note B
 | |
| c22             Most still to do; see docs/html/22_locale/*
 | |
| c23             See doxygroups.cc and Note B.  Notes on what invalidates
 | |
|                 iterators need to be added.
 | |
| c24             stl_iterator.h (__normal_iterator, other small TODO bits)
 | |
|                 stream iterators
 | |
| c25             stl_algo.h (lots of stuff)
 | |
| c26             <complex>, <valarray>, stl_numeric.h[26.4], Note A
 | |
| c27             ios_base callbacks and local storage
 | |
|                 basic_ios::copyfmt()
 | |
|                 std_streambuf.h's __copy_streambufs()
 | |
|                     " "           _M_* protected memfns (data has been done)
 | |
|                 fstream and sstream protected members
 | |
| 
 | |
| backward/*      Not scanned by doxygen.  Should it be?  Doubtful.
 | |
| 
 | |
| ext/*           Some of the SGI algorithm/functional extensions.
 | |
|                 All of rope/hashing/slist need docs.
 | |
| 
 | |
| __gnu_cxx       Tricky.  Right now ext/* are in this namespace.
 | |
| 
 | |
| -----------------------------------------------------------
 | |
| 
 | |
| 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.  Since we usually
 | |
| do not have the C code (to which the doxygen comments would be attached),
 | |
| this would need to be done in entirely separate files, a la doxygroups.cc.
 | |
| 
 | |
| B)  Huge chunks of containers and strings are described in common "Tables"
 | |
| in the standard.  These are pseudo-duplicated in tables.html.  We can
 | |
| use doxygen hooks like @pre and @see to reference the tables.  Then the
 | |
| individual classes do like the standard does, and only document members for
 | |
| which additional info is available.
 | |
| 
 | |
| 
 | |
| STYLE:
 | |
| stl_deque.h, stl_pair.h, and stl_algobase.h have good examples of what I've
 | |
| been using for class, namespace-scope, and function documentation, respectively.
 | |
| These should serve as starting points.  /Please/ maintain the inter-word and
 | |
| inter-sentence spacing, as this might be generated and/or scanned in the
 | |
| future.
 | |
| 
 | |
| 
 | |
| vim:ts=4:et:
 |