Re: [v3] pb_ds fixes for debug mode, valgrind

[Benjamin Kosnik <bkoz at redhat dot com>]

> Thanks for that link, I've been trying to deal with Doxygen's lack of
> C++0x support myself.

Yeah. This seems like the best-defined collection of gripes.
 
> Another issue not mentioned there is with a type such as:
> 
>   typedef decltype(expr) type; ///< type
> 
> which gets doxydised as a function not a typedef (presumably because
> of the parentheses.)

Type inference for generated template fun seems not a strong point.
Pity. There's so much fun to be had....

Introducing next year's summer of code, g++ plugin to parse c++ and
output graphviz! Structured in docbook xml even! Maybe by then the
legal situation GPL vis-a-vis GFDL will be sorted.

> The trick I'm using for allocator_traits (where I'm making heavy use
> of decltype) is:
> 
> private:
>   typedef decltype(expr) __type;
> public:
>   typedef __type type;  ///< type
> 
> The private type isn't documented, so the end result is pretty good -
> seeing the complex decltype expression doesn't help users anyway.

I am unfamiliar with "///<" markup. And don't see this in the current
generated docs.... show me a page or link to current web doxygen?

Sadly this is an area where macros make the generated doxygen output
cleaner, because you can just configure doxygen to deal with macros.

Lemme know if you have any ideas about derived template types. I am
planning on just grouping correctly for the modules and living without
correct hierarchy diagrams for the moment. To my great annoyance.

> For deleted functions I suggest:
> 
>   /// Deleted copy constructor
>   foo(const foo&) = delete;
> 
> Otherwise doxygen just includes it with no indication it's deleted.

Ah. We should be putting this into the doxygen style guide.

> I suppose maybe we could not bother with that and assume Doxygen will
> support deleted functions eventually.

Hmmm. 

-benjamin