Re: Boost Documentation Template questions

From: bill_kempf (williamkempf_at_[hidden])
Date: 2002-02-11 17:12:47

--- In boost_at_y..., "David Abrahams" <david.abrahams_at_r...> wrote:
> 
> ----- Original Message -----
> From: "bill_kempf" <williamkempf_at_h...>
> 
> > They've gotten to the point of generating XML finally?
> 
> They do say it's still experimental, but there appears to be lots 
of info
> there.
> Uh, on closer inspection, it's pretty limited. Nevermind :(
> 
> > Last I looked
> > they had a VERY rudimentary XML output (not suitable for 
translation
> > into actual documentation) and were under heavy redevelopment to
> > seperate the parser from the output engine(s).  If they've finally
> > got this work complete what would be really interesting is for 
some
> > entrepenurial developer to add an output engine to doxygen that
> > produced documentation structured in a manner consistent with the
> > templates.  Then we could leave the documentation in the code, 
where
> > it really belongs ;).
> 
> Feh. It seems like the very obvious idea of literate programming 
for C++ is
> still years away. I'm so disappointed.

You could make it happen a _little_ sooner by suggesting some 
language changes to the committee ;).  (Note: I realize it won't 
truly be any faster.)  In addition to literate programming along the 
same vein as JavaDoc (but I'd prefer the more meaningful metadata 
used by the standard) I'd love to see support for DBC in the 
language.  These two would actually be on the top of my wish list 
(before threads and socket support) if it weren't for the fact that I 
think they'd have some opposition in the committee.  The fact is, 
though, those two automation concepts can GREATLY improve the quality 
of code, and DBC at least requires language support, and even 
literate programming can benefit from language support (for instance, 
the documentation can be added to the XTI data that Bjarne is working 
on, so that the binary representation can be queried for 
documentation, which is a great benefit for plugins).

Bill Kempf