Re: [Doxygen-users] Problems with latest Doxygen

[Dimitri v. H. <di...@st...>]

On Wed, Jul 18, 2001 at 10:09:02AM +0200, Christoph Koegl wrote:
> 
> I encountered some problems with the latest snapshot 1.2.8-20010715 (don't know if
> earlier versions suffered all of these, too):
> 
> (1)
> Type names starting with a :: confuse Doxygen. Check out the following line:
> 
> inline ::std::size_t scanContractedLocus( const KeyIterator, const ::std::size_t,
>                                           const ::std::size_t );
> 
> Doxygen complains (line breaks by me for readibility):
> 
> CompSuffixTree.h:189: Warning: no matching class member found for 
>   std::size_t scanContractedLocus(const KeyIterator, const::std::size_t,
>                                   const::std::size_t)
> 
> Note that apparently the :: prefix of the return type did not cause any confusion but
> the :: prefix on the parameter types did.

I haven't been able to reproduce this. What does the definition of 
scanContractedLocus look like?

> 
> (2)
> This is a problem persisting from earlier version. Perhaps I am at fault.
> 
> There are the following entries in the Doxyfile:
> 
> ENABLE_PREPROCESSING   = YES
> MACRO_EXPANSION        = YES
> EXPAND_ONLY_PREDEF     = YES
> SEARCH_INCLUDES        = YES
> EXPAND_AS_DEFINED      = POOL_ALLOCATOR_MEMORY_INIT_TEMPLATE_INNER_2
> 
> I include a file containing the following:
> 
> #define POOL_ALLOCATOR_MEMORY_INIT_TEMPLATE_INNER_2( tname, param1, param2, iname ) \
>   template< class param1, class param2 >\
>   Util::PoolAllocator< typename tname< param1, param2 >::iname >\
>   tname< param1, param2 >::iname::s_allocator;
> 
> In Trie.cc I have the following line (line 1270):
> 
> POOL_ALLOCATOR_MEMORY_INIT_TEMPLATE_INNER_2( Trie, Key, Info, Node )
> 
> which the preprocessor expands to
> 
> template< class Key, class Info >
> Util::PoolAllocator< typename Trie< Key, Info >::Node >
> Trie< Key, Info >::Node::s_allocator;
> 
> But Doxygen complains:
> 
> Trie.cc:1270: Warning: no matching class member found for 
>   Util::PoolAllocator< typename Trie< Key, Info >::iname > s_allocator()
> 
> Note the un-expanded string iname and Doxygen's assumption that s_allocator is a
> function. What's happening here?

It is a bug in doxygen's preprocessor. Will be fixed. 
If your remove the spaces in front of the macro's formal arguments it 
will work.

> (3)
> This is also a persisting problem. I suppose it is not easy to fix.
> 
> I have the following class definition in SomeFile.h:
> 
> class A
> {
>   private:
> 
>     class IImpl
>     {
>       // Abstract mfuns.
>     };
>     
>     template< class CP >
>     class Impl : public IImpl
>     {
>       private:
> 
>         class Sometype {};
> 
>         class ISomething
>         {
>           // Abstract mfuns.
>         };
> 
>         template< class RI >
>         class Something : public ISomething
>         {
>           public:
> 
>             SomeType begin( ) const;
>         }
>     }
> };
> 
> In File SomeFile.cc I have the following member function definition:
> 
> template< class CP >
> template< class RI >
> A::Impl< CP >::SomeType
> A::Impl< CP >::Something< RI >::
> begin(
>     )
> const
> {
>   // Whatever.
> }
> 
> Doxygen complains:
> 
> SomeFile.cc:2035: Warning: no matching class member found for 
>   A::Impl< CP >::SomeType begin() const
> 
> Somehow Doxygen seems to be unable to find the class of which begin is a member
> function. Ok, member class templates of member class templates might occur too often,
> so it is probably not a problem lots of people run into.
> 

When it comes to matching member declarations against member definitions, 
doxygen is basically still limited to one template class at the top level. 
This was once all my compiler supported, so I didn't design-in support 
for multiple template scopes :-( I've already made some internal changes that
should make it easier to support this in the future, but it is still work to do.

Regards,
  Dimitri