Boost Docs :
From: Pavol Droba (droba_at_[hidden])
Date: 2003-07-15 07:59:40
On Fri, Jul 11, 2003 at 10:04:35AM -0700, Douglas Gregor wrote:
> > 1. For some functins, a link is whole function definition, not just the
> > function name.
> That's by design, although there was a bug where a function with a template
> header on a separate line would have the rest of its declaration
> highlighted, and that looks quite silly. I've fixed the bug part. I actually
> like the whole-definition highlighting when it fits on one line, because it
> gives me a lot of clickin' latitude. But since this is a stylistic issue, we
> can always agree to disagree and add a stylesheet parameter :)
It is probably the matter of taste, important is to have a uniform behaviour,
otherwise we get a mess.
> > 2. I would suggest to increase the treshold for moving a retunr value to
> > a separate line. It should be at least 10-15 chars.
> Done. It's at 12 now, because 17 is too large :)
> > 4. I have tried to move DTD and XLS directory defintions to
> > user-config.jam,
> > as you suggested, but they are not read.
> Odd. Did you put user-config.jam into $HOME or $BOOST_BUILD_PATH? The BBv2
> docs say that it looks there...
I'll try to play with it a little more. I'm working under win platform, so I'm
not wondering that there are some problems there...
> > 2. I would reorganize detailed function description a little bit, if it is
> > possible.
> > - 1. Parameters
> > - 2. Return value
> > - 3. Description
> > - 4. ?Notes
> > - 5. ?Examples
> This is very unlikely to happen. BoostBook is deliberately modeled afer the
> C++ standard's method of documentation, which is very rigid in the ordering
> of the semantic clauses, and I really don't think we want to break that to
> support Doxygen extensions like parameter lists. Actually, I'm starting to
> wonder if the problem is because the Doxygen description should be mapped
> over to <effects> instead of coming before normal semantic clauses...
This reasoning is fine for me. Question is if the behaviour should not be
After all, there is quite a difference between user manual and C++ Standard