doxygen-users — List for users of doxygen

RE: [Doxygen-users] Documenting C structs

[Wagner, V. <VW...@se...>]

given that the differences between struct and class is minimal, what's wronw
with the way it documents them now?

-----Original Message-----
From: Clayton Carter [mailto:crc...@cs...]
Sent: Tuesday, 2001 July 24 17:36
To: dox...@li...
Subject: [Doxygen-users] Documenting C structs


	What have folks found to be the best way of documenting C
structs?  I was hoping that there'd be a command `@member' so that
structs could be documented like functions.  For instance, we've got
this:

/**
 * Function to init some data
 * @param inFile ...
 * @return ...
 */
int init_data( char *inFile )

	and we can also use the `/*!<' syntax to document `inFile'
right where we define it.  Anyway, it seems as this on location
documentation is only option when working with structs.  I'd like
something like this:

/**
 * @struct data
 * @brief ...
 * @member mins ...
 * @member maxs ...
 * @member means ...
 * etc.
 */

typedef struct {
  double mins, maxs, means, medians, sigs, totals;
} data;


	Please chastise me if I'm way off base here.  I've scanned the
docs, but not seen anything like what [I think] I'm talking about.
Thanks.

--pc

-- 
Clayton Carter   crc...@cs...
"My mom says I'm the handsomest guy in school."

_______________________________________________
Doxygen-users mailing list
Dox...@li...
http://lists.sourceforge.net/lists/listinfo/doxygen-users


This transmission may contain information that is privileged, confidential
and exempt from disclosure under applicable law.
If you are not the intended recipient, you are hereby notified that any
disclosure, copying, distribution, or use of the information contained
herein (including any reliance thereon) is STRICTLY PROHIBITED.
If you received this transmission in error, please immediately contact the
sender and destroy the material in its entirety, whether in electronic or
hard copy format.
Thank you

[Doxygen-users] Alternate Grouping

[Clayton C. <crc...@cs...>]

	This question is independent of my last, but I'll use the same
examples.

	Anyway, suppose I have that simple `data' struct:

typedef struct {
  double mins, maxs, means, medians, sigs, totals;
} data;

	Better yet, suppose I picked better names for the variables:

typedef struct {
  double min_val, max_val, mean_val, median_val, std_dev, total;
} data;

	Is there any way to group these all together so that they are
all documented *as one*.  For instance, I'd like to do this:

/**
 * @struct data
 * @brief ...
 * @member min_val,max_val,mean_val,median_val,std_dev,total
 *         Self explanatory variables.  Our means to the end.
 */

	and have it formatted (in output) as such:

Field Documentation

  double data::min_val, max_val, mean_val, etc.

     Self explanatory variables.  Our means to the end.

     Definition at line xx of file bing.h. 


	(I mean the above formatting to be the same as it is
currently, except that all of the variables in the @member appear
listed together.)  Is a grouping of this nature possible, or does
anyone thing that it'd be useful (or, possibly, confusing)?

	In case you couldn't tell, I'm new to Doxygen.  Thanks!

--c

-- 
Clayton Carter   crc...@cs...
"My mom says I'm the handsomest guy in school."

[Doxygen-users] Documenting C structs

[Clayton C. <crc...@cs...>]

	What have folks found to be the best way of documenting C
structs?  I was hoping that there'd be a command `@member' so that
structs could be documented like functions.  For instance, we've got
this:

/**
 * Function to init some data
 * @param inFile ...
 * @return ...
 */
int init_data( char *inFile )

	and we can also use the `/*!<' syntax to document `inFile'
right where we define it.  Anyway, it seems as this on location
documentation is only option when working with structs.  I'd like
something like this:

/**
 * @struct data
 * @brief ...
 * @member mins ...
 * @member maxs ...
 * @member means ...
 * etc.
 */

typedef struct {
  double mins, maxs, means, medians, sigs, totals;
} data;


	Please chastise me if I'm way off base here.  I've scanned the
docs, but not seen anything like what [I think] I'm talking about.
Thanks.

--pc

-- 
Clayton Carter   crc...@cs...
"My mom says I'm the handsomest guy in school."

Re: [Doxygen-users] Question about Doxygen & Rational Rose / RTF bug report

[Paul B. <tri...@sp...>]

  You might want to consider an input filter.  From the sound of it you've 
got some pretty basic fixing up required, so a little perl script would do 
the job nicely.  Had to do the same thing a couple of years back to satisfy a 
guru that refused to use /* ... */ in his C++, so I wrote a filter that would 
combine blocks of //! into a single C-style comment block.

  -P

On Monday 23 July 2001 18:09, you wrote:
> Hello,
>
> I am working on the documentation of a CORBA interface and would like to
> use Doxygen to get this done.
> A model of the interface has been created in Rational Rose 2001 E, and
> comments are in the Rose Model as well.
> I have two problems with the IDL files generated in Rose:
> - The first one is the fact that all IDL file comments start with "/* ",
> and they're seems to be no way to change this style.
> - The second one is the fact that Rose adds comments with @roseuid tags to
> the file and merges this tag with the preceding textual comment.
> Since I expect frequent updates, I would like to avoid manual tweaking in
> the ouput. Is any body doing something similar and knows a workaround? I'd
> really appreciate any help.
>
> I've also observed a strange behavior in generated RTF files and assume
> that this is either a bug or a version incompatibility. My configuration
> is: Doxygen 1.2.8.1, Win 2000 AS English, Word 2000 German. In the RTF
> output, class reference section have a TC and an XE field in front of the
> include statement. When I open an RTF file, update it with F9, save it, and
> open it again, the content of the TC field will be displayed as visible and
> printable text at the beginning of the corresponding line. I believe that
> this is due to a bug in the structure of the TC field: The switch that
> determines the TOC level should be at the end of the field, but it is in
> the centre. When I adjust the field structure manually, the behavior goes
> away.
>
> Thanks for your help in advance
>
> Susanne Muris

----------------------------------------
Content-Type: application/ms-tnef; charset="iso-8859-1"; name="winmail.dat"
Content-Transfer-Encoding: base64
Content-Description: 
----------------------------------------

-- 
Paul Bohme - Geek Iconoclast
tri...@sp... - http://www.sponheim.org
Programming today is a race between software engineers striving to build 
bigger and better idiot-proof programs and the universe trying to produce 
bigger and better idiots.  So far, the universe is winning.  - Richard Cook

[Doxygen-users] Question about Doxygen & Rational Rose / RTF bug report

[<Sus...@t-...>]

Hello,

I am working on the documentation of a CORBA interface and would like to use
Doxygen to get this done.
A model of the interface has been created in Rational Rose 2001 E, and
comments are in the Rose Model as well. 
I have two problems with the IDL files generated in Rose:
- The first one is the fact that all IDL file comments start with "/* ", and
they're seems to be no way to change this style.
- The second one is the fact that Rose adds comments with @roseuid tags to
the file and merges this tag with the preceding textual comment.
Since I expect frequent updates, I would like to avoid manual tweaking in
the ouput. Is any body doing something similar and knows a workaround? I'd
really appreciate any help.

I've also observed a strange behavior in generated RTF files and assume that
this is either a bug or a version incompatibility. My configuration is:
Doxygen 1.2.8.1, Win 2000 AS English, Word 2000 German. In the RTF output,
class reference section have a TC and an XE field in front of the include
statement. When I open an RTF file, update it with F9, save it, and open it
again, the content of the TC field will be displayed as visible and
printable text at the beginning of the corresponding line. I believe that
this is due to a bug in the structure of the TC field: The switch that
determines the TOC level should be at the end of the field, but it is in the
centre. When I adjust the field structure manually, the behavior goes away.

Thanks for your help in advance

Susanne Muris

[Doxygen-users] Controlling order in RTF output?

[Dan M. <dm...@Cr...>]

I know this has been asked before, but I was unable to find an answer by
searching either my memory or the Web.

I am generating RTF output for the first time. I've been generating only
HTML in the few months that I've been using doxygen.

I'm also adding supplemental documentation to a library, using a separate
file containing @page sections. I don't want to add everything as
subsections of the main page, because it will be far too large for the HTML
output by the time I'm done.

Can I control the order of the output in the RTF file? My supplemental pages
keeps showing up at the end of the document. I've tried using the INPUT tag
to force the files to be processed in a specific order, as follows:

FILE_PATTERNS   = *.h *.cpp
INPUT           = ..\MyLib\main.dox_txt ..\MyLib\

But this doesn't seem to help. None of the options seem to be relevant,
neither the RTF style sheet nor the extention file seem to address this, and
I didn't see anything on the TODO/Wish list that referenced it.

Have I missed something? Or is it just not possible to control this right
now? If the latter, could it be added to the wish list, please?

- Dan Muller

[Doxygen-users] Doxygen-1.2.8-20010723 in CVS

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

Hi,

In this week's release the following has changed:
-----------------------------------------------------------------------------
+ BUG: Reworked part of the template handling. Doxygen should now be
       capable of handling nested template classes correctly. Please test
       this if you are using these contructs. Thanks to Christoph Koegl
       for providing some difficult test cases.
+ CHG: Started moving the XML output back into doxygen. As a result the
       GENERATE_XML option has reappeared.
+ BUG: Fixed parse problem when parsing << as part of the first
       argument of a typedef.
+ BUG: The LATEX_HEADER-config option disabled the \mainpage-output
       (thanks to Eric Reinhart for the fix).
+ BUG: Merged a patch by Erik Zeek, to allow compilation under BCB5
+ BUG: Spaces in preprocessor macros arguments were not treated properly.
+ ADD: Olexij Tkatchenko has added support for the Ukrainian language.
       Included update for Portuguese sent by Rui Lopes.
+ BUG: Fixed argument matching bug that caused doxygen to treat
       f(type t) and f(type_t t) as the same function.
-----------------------------------------------------------------------------
Enjoy,
  Dimitri

[Doxygen-users] Doxygen and XML... (was RE: [Doxygen-develop] Adding of new (all) HTML entities?)

[Prikryl,Petr <PRI...@sk...>]

Dimitri wrote
> Xavier wrote
> > Besides, I know what to do with HTML and LaTeX (maybe not for
> > all symbols, I have to check in my documentation) but I don't know
> > what to do with man.
> 
> This has always been a mistery to me too.

Another reason for choosing DocBook XML.  The existing XML tools
can be used to produce man pages (I believe I have read recently
something about that in one of the DocBook mailing lists).

I.e. sources --> internal XML --(alternatively)--> DocBook XML --
transformation XML tools
plus (as other alternatives to the DocBook tool chain) the original 
doxygen's HTML generator,  LaTeX generator, etc.

I feel we are converging!  As I still think that DocBook be 
the good choice, the internal XML should not create 
obstacles.  This is the reason for further analysis.

I have just first touch with DocBook.  I do not have 
good working knowledge.  We should possibly search for
some DocBook experts here.  Do you agree?
Is any DocBook expert reading this? 
(Posted also to doxygen users mailing list for that reason.)

Regards, Petr

-- 
Petr Prikryl, SKIL, spol. s r.o., pri...@sk...

Re: [Doxygen-users] Question about Preprocessing

[Patrick O. <Pat...@pa...>]

On Fri, Jul 20, 2001 at 04:21:58PM -0700, Zhen Yin wrote:
> QUESTION:
> Is thers any way doxygen can show both case, in both "if" section and
> "else" section?
> Set MACRO_EXPANSION to YES only show the case in "else" section.

I do that with an input filter that removes the "#ifdef|if|else|elif|endif".
I don't think doxygen has a feature for that itself.

Bye, Patrick
-- 
// pallas  GmbH  ............  Patrick Ohly  .............
   Hermuelheimer Str. 10       Software-Engineer
   D-50321 Bruehl, Germany     po...@pa...
   fax +49-(0)2232-1896-29     phone  +49-(0)2232-1896-30 
   http://www.pallas.com 
..........................................................

[Doxygen-users] Question about Preprocessing

[Zhen Y. <zy...@le...>]

In the doxygen configuration file:

if
ENABLE_PREPROCESSING   = YES
MACRO_EXPANSION        = NO

doxygen will do partially preprocessing. it evaluates conditional
compilation statements (like #if) and evaluates macro definitions, but
it does not
perform macro expansion.

As in the following example:

#define VERSION 200
#define CONST_STRING const char *

#if VERSION >= 200
  static CONST_STRING version = "2.xx";
#else
  static CONST_STRING version = "1.xx";
#endif

The result will be:

#define VERSION
#define CONST_STRING

static CONST_STRING version = "2.xx";

QUESTION:
Is thers any way doxygen can show both case, in both "if" section and
"else" section?
Set MACRO_EXPANSION to YES only show the case in "else" section.

Thank you.

Zhen

RE: [Doxygen-users] Duplicated output

[Cipronido <cip...@ar...>]

You were right.
I had checked the recursive option and also had given the paths to my
sources, so files were scanned several times.
I had also 1.2.8 version with duplicated parameters, which versions 1.2.8.1
solves.

Now all works.Excelent program!!

Thanks

[Doxygen-users] Error Message When Trying To Search Archives

[Catenacci, O. <Ono...@co...>]

Hi Geoff,

A lot of people have been seeing that error.  There's no telling when it
will be fixed.  

I don't think there is any alternative for searching old messages.

--
Onorio Catenacci
Developer - QACenter Common Technologies
(248) 737-7300 x12756
Cube 4536 - Allied Building

"Chutzpah n. The quality of a person who murders both of his parents and
then pleads for mercy because he is an orphan."


> 
> When I try to search the doxygen-users mail archive at
> http://www.geocrawler.com/lists/3/SourceForge/11668/0/, I receive the
> following error:
> 
>    Your search for
> 
>       htsearch detected an error. Please report this to the returned
>    matches
> 
> 
>       webmaster of this site. The error message is:
> 
>       Unable to read configuration file
>    '/bigassraid/htdig//conf/11668.conf'
> 
> I'm not sure who to report this to, so I thought I'd ask here 
> if anyone
> knows how to search the doxygen-users mail archive.

[Doxygen-users] (no subject)

[Geoff A. <gd...@us...>]

When I try to search the doxygen-users mail archive at
http://www.geocrawler.com/lists/3/SourceForge/11668/0/, I receive the
following error:

   Your search for

      htsearch detected an error. Please report this to the returned
   matches


      webmaster of this site. The error message is:

      Unable to read configuration file
   '/bigassraid/htdig//conf/11668.conf'

I'm not sure who to report this to, so I thought I'd ask here if anyone
knows how to search the doxygen-users mail archive.

Thanks,
Geoff Alexander, Ph.D.
919/254-5216 T/L 444-5216
CMVC95 WebDAV Development
IBM Corporation
RTP, NC

[Doxygen-users] RTF problems

[<Mar...@no...>]

Hi Doxygeners!

Maybe you can help me solving following problems (using win32-1.2.8.1):

Some of this questions have been posted some weeks ago, but it might have
happened that meanwhile... ;)


## 1 ##

Suppose following header file comment:

/**
...
 * <PRE>
 * -------------------    -----------------------    -------
 * | mem buf       1 |    | mem buf 2           |    | mb3 |
 * -------------------    -----------------------    -------
 * </PRE>
...
*/

In HTML output I get correct stuff:

   -------------------    -----------------------    -------
   | mem buf       1 |    | mem buf 2           |    | mb3 |
   -------------------    -----------------------    -------


But in RTF the output is as follows (with grey background):

 -------------------    -----------------------    ------- | mem buf       1
|    | mem buf 2           |    | mb3 | -------------------
-----------------------    ------- 


i.e. the linebreaks are not considered.
(If I use <BR> in header the RTF output is ok, but the HTML contains empty
lines and looks ugly.)

Any idea to solve this (format my headers to get readable output in both
HTML and RTF)?


## 2 ##

Precondition: RTF Extension created with 'doxygen -ertf rtf_ext' and invoked
via RTF_EXTENSIONS_FILE = rtf_ext.
This works so far, but it seems not be possible to use environment variables
in this extension file. They are just listed as text, although they do work
in the 'calling' configuration file.

Is this feature not implemented or am I just doing someyhing wrong?


## 3 ##
Is there any way to tell m$-word to automatically update RTF field codes
(simulate STRG-A, F9)?

No real hope to get an answer... 


Thanks a lot for any suggestion or tip!

BR,
 Markus Lepper


PS: Dimitri: Great tool anyway and excellent job done!!!

Re: [Doxygen-users] Duplicated output

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

On Wed, Jul 18, 2001 at 11:21:08PM +0200, Jens Seidel wrote:
> On Wed, 18 Jul 2001, Cipronido wrote:
> 
> >
> > Hi:
> >
> > I´m using last version of doxygen (1.2.8) and all the classes,
> > descriptions,member functions and more are duplicated (even tripled) and i
> > dont know why.I.m using it from KDevelop menu.
> >
> > Could somebody help me?
> >
> > Thanks
> >
> 
> A similar bug (parameters appeared twice) is fixed in doxygen 1.2.8.1.
> Please try this version or a newer CVS version.

Also, make sure input files occur only once on the INPUT line 
(not twice or even three times).

Regards,
  Dimitri

Re: [Doxygen-users] Duplicated output

[Jens S. <jen...@hr...>]

On Wed, 18 Jul 2001, Cipronido wrote:

>
> Hi:
>
> I´m using last version of doxygen (1.2.8) and all the classes,
> descriptions,member functions and more are duplicated (even tripled) and i
> dont know why.I.m using it from KDevelop menu.
>
> Could somebody help me?
>
> Thanks
>

A similar bug (parameters appeared twice) is fixed in doxygen 1.2.8.1.
Please try this version or a newer CVS version.

Re: [Doxygen-users] How to document access control when grouping of class members

[Geoff A. <gd...@us...>]

Geoff Alexander wrote:
> Also, there is no indication of the member's access control in the
> Member Function Documentation section.  How can include each member's
> access control the Member Function Documentation section?

I missed the [protected] and [private] in the Member Function
Documentation section, so this isn't as bad as I first thought.  Still
it would be nice to have some sort of indication in grouped member list.

Thanks,
Geoff Alexander, Ph.D.
919/254-5216 T/L 444-5216
CMVC95 WebDAV Development
IBM Corporation
RTP, NC

[Doxygen-users] Duplicated output

[Cipronido <cip...@ar...>]

Hi:

I=B4m using last version of doxygen (1.2.8) and all the classes,
descriptions,member functions and more are duplicated (even tripled) and =
i
dont know why.I.m using it from KDevelop menu.

Could somebody help me?

Thanks

[Doxygen-users] No warning for undocumented member in group

[Geoff A. <gd...@us...>]

I run doxygen 1.2.8.1 with WARN_IF_UNDOCUMENTED set to YES on the
following file:

---
#ifndef TEST1_HPP
#define TEST1_HPP

//
// Include files.
//
#include <exception>

//
// MyNamespace namespace.
//
namespace MyNamespace
{

  /**
   * Test1 is a class for testing doxygen style comments.
   *
   * This the Test1 class's detailed description.
   *
   * @nosubgrouping
   */

  class Test1
  {

    /**
     * @name Additional Class Methods
     */
    //@{

      /**
       * This is method1's brief description.
       *
       * This is method1's detailed description.
       *
       * @param m parameter 1
       * @param n parameter 2
       *
       * @returns the return value
       *
       * @exception std::exception Exception description
       *
       */
      public:
        int method1( int m, int n ) const throw( std::exception );

      public:
        int method2( int m, int n ) const throw( std::exception );

    //
    // End Additional Class Methods
    //
    //@}

    public:
      int method3( int m, int n ) const throw( std::exception );

  //
  // End Test1 definition.
  //
  };

//
// End MyNamespace namespace.
//
}

//
// End include only once.
//
#endif
---

I get the following warning message as excepted:

  /home/gdlxn/Test1.hpp:56 Warning: Member method3 of class
  MyNamespace::Test1 is not documented.

However, I don't get a warning message for the undocumented method2.  Why?

BTW, it would be nice setting WARN_IF_UNDOCUMENTED to YES would warn
about other undocumented entities, such as classes,  namespaces, global
functions, etc.  in addition to warning about undocumented members.

Geoff Alexander, Ph.D.
919/254-5216 T/L 444-5216
CMVC95 WebDAV Development
IBM Corporation
RTP, NC

[Doxygen-users] How to document access control when grouping of class members

[Geoff A. <gd...@us...>]

I'm documenting a class with grouping of my class members.

This generates a list of methods in the class's documentation (in the
generated HTML) as follows:

   group heading 1

   member1

   member2

   member3

   .
   .
   .

   group header 2

   .
   .
   .

The problem is that there is no indication of the member's access
control (public, protected, or private).How can I use grouping and
have each member's access documented?

Also, there is no indication of the member's access control in the
Member Function Documentation section.  How can include each member's
access control the Member Function Documentation section?

In the class's member list, there is an indication if a member is
protected ([protected]) or private ([private]).  Is there a way to
have [public] included for public members.

Thanks,
Geoff Alexander, Ph.D.
919/254-5216 T/L 444-5216
CMVC95 WebDAV Development
IBM Corporation
RTP, NC

Re: [Doxygen-users] Problems with latest Doxygen

[Christoph K. <ko...@in...>]

> > 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?

This is a member function of a nested class of a class template:

template<class KeyIterator, class Info>
class CompSuffixTree
{
  public:

    class LILOSubwordIterator
    {
      public:

        inline ::std::size_t scanContractedLocus( const KeyIterator, const ::std::size_t,
                                                  const ::std::size_t );
    };
};

In the .cc file:

template<class KeyIterator, class Info>
::std::size_t
CompSuffixTree<KeyIterator,Info>::LILOSubwordIterator::
scanContractedLocus( const KeyIterator suffix, const ::std::size_t length,
                     const ::std::size_t exdepth )
{
  // Whatever
}


Cheers, Christoph

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

Re: [Doxygen-users] doxygen fails to document class A struct B, workaround?

[Greger H. <gre...@ya...>]

"Wagner, Victor" wrote:
No, breaks existing code, this package is used by millions all around the
world and that is an impossible solution

> yeah, run a "splat" to change all the occurrences of your struct A to
> something like struct struct_A.
>
> -----Original Message-----
> From: Greger Haga [mailto:gre...@ya...]
> Sent: Tuesday, 2001 July 17 02:28
> To: dox...@li...
> Subject: [Doxygen-users] doxygen fails to document class A struct B,
> workaround?
>
> Hi!
> Have a problem: one class and one struct are declared with the same
> name: class A and struct A. It is indeed illegal to have two types of
> the same name to compile I know, nevertheless both have to be
> documented. Doxygen treats both as the same!The resulting docs mix
> members of both the struct and the class into the class's documentation.
> The struct is not documented at all. Does anyone know of a workaround to
> fool doxygen to treat them as diffferent entities?
>
> Greger
>
> _________________________________________________________
> Do You Yahoo!?
> Get your free @yahoo.com address at http://mail.yahoo.com
>
> _______________________________________________
> Doxygen-users mailing list
> Dox...@li...
> http://lists.sourceforge.net/lists/listinfo/doxygen-users
>
> This transmission may contain information that is privileged, confidential
> and exempt from disclosure under applicable law.
> If you are not the intended recipient, you are hereby notified that any
> disclosure, copying, distribution, or use of the information contained
> herein (including any reliance thereon) is STRICTLY PROHIBITED.
> If you received this transmission in error, please immediately contact the
> sender and destroy the material in its entirety, whether in electronic or
> hard copy format.
> Thank you
>
> _______________________________________________
> Doxygen-users mailing list
> Dox...@li...
> http://lists.sourceforge.net/lists/listinfo/doxygen-users


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

[Doxygen-users] Problems with latest Doxygen

[Christoph K. <ko...@in...>]

Hi all.

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.

(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?

(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.

Problems (1) seems to be new, problems (2) and (3) were already reported (by me) some
time ago. What are the chances to get them fixed?

Cheers, Christoph

PS. Btw, did I mention what a great tool Doxygen is? It's the greatest. Absolutely.

[Doxygen-users] 1.2.8.1: minor problem with configure -help

[Geoff A. <gd...@us...>]

I recently encountered a minor problem with configure -help in doxygen
1.2.8.1 where configure -help states that the default install tool is
install:

     --install name        Use `name' as the name of the GNU install tool
                           [default: install]

However, the default value code in configure is ginstall:

   f_insttool=ginstall

Geoff Alexander, Ph.D.
919/254-5216 T/L 444-5216
CMVC95 WebDAV Development
IBM Corporation
RTP, NC