doxygen-users — List for users of doxygen

Re: [Doxygen-users] How can I add documentation for an inherited member function, that isn't overridden in the derived lass?

[Richard D. <Ri...@Da...>]

The fundamental issue is you are wanting to document a function that really doesn't exist. (I personally use a DOXYGEN define to handle your conditional situation, _DOC is in the implementation namespace, so unless you are taking that responsibility, you shouldn't use it).

My feeling about what you are describing is feeling like Base::doFoo isn't being documented properly. It is apparently using another virtual function to provide a hook that provides this differing functionality. I see a couple ways to handle this:

1) Derived and Base are considered to be part of a single package, and this linkage is a private implementation detail. In this case Base DOES know about Derived (at a design level, if not a class level) so it makes sense to document the various behaviors of the full package in the documentation.

2) Derived and Base are considered to be different packages, and the virtual function may be an implementation detail (perhaps documented in an implementation documentation package). Here, since the linkage is hidden in implementation details, but Base::doFoo() knows that its behavior is dependent on derived behavior, it should mention this, and point to the derived documentation for more details. You want to do this by creating documentation for a non-existent Derived::doFoo(), but it could go into a section of the general class documentation (or we can make the override not non-existent).

3) As above, but we are willing to disclose the virtual function, in which case Base::doFoo() can reference that function, and the details for the derived class can put the documentation in that member function.

4) We can make the linkage function a documented part of the interface,  so the interaction between doFoo() and the implementFoo() function is fully documented, and Derived:implementFoo() will be documented with the behavior.

-----Original Message-----
From: Stefan Ludewig [mailto:kai...@ex...] 
Sent: Monday, February 13, 2017 9:32 AM
To: Richard Damon <Ri...@da...>; dox...@li...
Subject: RE: [Doxygen-users] How can I add documentation for an inherited member function, that isn't overridden in the derived lass?

Hi Richard.

"I do wonder a bit, about why the Base::doFoo() needs a different documentation when is it used as inherited by Derived."
Well, it's a client-server solution and the function to document is part of the client code base. doFoo() closes the connection. Base just handles the connection, while Derived adds logic about rooms that one can join and leave when connected (multiple clients can interact with each other when they are inside the same room). Now when a client closes the connection while it is inside a room, then the server will also interpret that as leaving the room.
So the doc of Derived::doFoo() needs to mention that closing the connection also means leaving any currently joined room, while Base is not even aware of the existence of rooms, so that Base::doFoo() should not mention this, as not every class that derives from it does implement room logic.

" One possible solution, is to create a real Derived::doFoo(), something
like:

   doFoo(void) { Base::doFoo(); }

This function should have zero cost, as it will be inlined and be exactly like a call to Base::doFoo at the call site. Now it can be documented, as it exists."
I hoped there was a way to add a different doc for the inherited function, without the need to override it with a dummy-wrapper that has no purpose at all aside from doc, as I feel that such dummy-functions pollute the API.

My current approach is
#if _DOC
    doFoo(void);
#endif

With _DOC only getting defined by Doxygen and not by any project for any compiler, but this feels like a workaround for a missing Doxygen feature to me.

Kind regards,
Stefan.

-----Original Message-----
From: Richard Damon [mailto:Ri...@Da...]
Sent: Freitag, 10. Februar 2017 23:14
To: 'Stefan Ludewig'
Subject: RE: [Doxygen-users] How can I add documentation for an inherited member function, that isn't overridden in the derived lass?

Your first problem is that there really isn't a Derived::doFoo, so there are real reason that you can't document such a thing (technically, when you say Derived::doFoo(), it is looking in the 'namespace' of Derived for doFoo(), and find the inherited version lf Base::doFoo() )

I do wonder a bit, about why the Base::doFoo() needs a different documentation when is it used as inherited by Derived.

One possible solution, is to create a real Derived::doFoo(), something
like:

   doFoo(void) { Base::doFoo(); }

This function should have zero cost, as it will be inlined and be exactly like a call to Base::doFoo at the call site. Now it can be documented, as it exists.

-----Original Message-----
From: Stefan Ludewig [mailto:kai...@ex...]
Sent: Friday, February 10, 2017 8:49 AM
To: dox...@li...
Subject: [Doxygen-users] How can I add documentation for an inherited member function, that isn't overridden in the derived lass?

Hi.



I have the following situation:
class Base
{
public:
    doFoo(void);
};

class Derived : public Base
{
public:
    doBar(void);
};



Now I have documented Base::doFoo() and Derived::doBar(), but I need to also document Derived::doFoo() with a doc that differs from the of Base::doFoo(), although Derived does not override the implementation of doFoo().
Is this possible? If yes, how?

/* @fn Derived::doFoo() */ makes Doxygen complain that it can't find a matching class member for doFoo() in Derived.



Kind regards,
Stefan.

--
--
Exit Games | +49 40 413 596 0

Executive Christof Wegmann, CTO
Trade Registry / Amtsgericht Hamburg, Germany HRB 85991

We Make Multiplayer Simple | www.photonengine.com

--------------------------------------------------------------------------
--
--
Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________
Doxygen-users mailing list
Dox...@li...
https://lists.sourceforge.net/lists/listinfo/doxygen-users

--
--
Exit Games | +49 40 413 596 0

Executive Christof Wegmann, CTO
Trade Registry / Amtsgericht Hamburg, Germany HRB 85991

We Make Multiplayer Simple | www.photonengine.com

Re: [Doxygen-users] How can I add documentation for an inherited member function, that isn't overridden in the derived lass?

[Stefan L. <kai...@ex...>]

Hi Richard.

"I do wonder a bit, about why the Base::doFoo() needs a different
documentation when is it used as inherited by Derived."
Well, it's a client-server solution and the function to document is part
of the client code base. doFoo() closes the connection. Base just handles
the connection, while Derived adds logic about rooms that one can join and
leave when connected (multiple clients can interact with each other when
they are inside the same room). Now when a client closes the connection
while it is inside a room, then the server will also interpret that as
leaving the room.
So the doc of Derived::doFoo() needs to mention that closing the
connection also means leaving any currently joined room, while Base is not
even aware of the existence of rooms, so that Base::doFoo() should not
mention this, as not every class that derives from it does implement room
logic.

" One possible solution, is to create a real Derived::doFoo(), something
like:

   doFoo(void) { Base::doFoo(); }

This function should have zero cost, as it will be inlined and be exactly
like a call to Base::doFoo at the call site. Now it can be documented, as
it exists."
I hoped there was a way to add a different doc for the inherited function,
without the need to override it with a dummy-wrapper that has no purpose
at all aside from doc, as I feel that such dummy-functions pollute the
API.

My current approach is
#if _DOC
    doFoo(void);
#endif

With _DOC only getting defined by Doxygen and not by any project for any
compiler, but this feels like a workaround for a missing Doxygen feature
to me.

Kind regards,
Stefan.

-----Original Message-----
From: Richard Damon [mailto:Ri...@Da...]
Sent: Freitag, 10. Februar 2017 23:14
To: 'Stefan Ludewig'
Subject: RE: [Doxygen-users] How can I add documentation for an inherited
member function, that isn't overridden in the derived lass?

Your first problem is that there really isn't a Derived::doFoo, so there
are real reason that you can't document such a thing (technically, when
you say Derived::doFoo(), it is looking in the 'namespace' of Derived for
doFoo(), and find the inherited version lf Base::doFoo() )

I do wonder a bit, about why the Base::doFoo() needs a different
documentation when is it used as inherited by Derived.

One possible solution, is to create a real Derived::doFoo(), something
like:

   doFoo(void) { Base::doFoo(); }

This function should have zero cost, as it will be inlined and be exactly
like a call to Base::doFoo at the call site. Now it can be documented, as
it exists.

-----Original Message-----
From: Stefan Ludewig [mailto:kai...@ex...]
Sent: Friday, February 10, 2017 8:49 AM
To: dox...@li...
Subject: [Doxygen-users] How can I add documentation for an inherited
member function, that isn't overridden in the derived lass?

Hi.



I have the following situation:
class Base
{
public:
    doFoo(void);
};

class Derived : public Base
{
public:
    doBar(void);
};



Now I have documented Base::doFoo() and Derived::doBar(), but I need to
also document Derived::doFoo() with a doc that differs from the of
Base::doFoo(), although Derived does not override the implementation of
doFoo().
Is this possible? If yes, how?

/* @fn Derived::doFoo() */ makes Doxygen complain that it can't find a
matching class member for doFoo() in Derived.



Kind regards,
Stefan.

--
--
Exit Games | +49 40 413 596 0

Executive Christof Wegmann, CTO
Trade Registry / Amtsgericht Hamburg, Germany HRB 85991

We Make Multiplayer Simple | www.photonengine.com

--------------------------------------------------------------------------
--
--
Check out the vibrant tech community on one of the world's most engaging
tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Doxygen-users mailing list
Dox...@li...
https://lists.sourceforge.net/lists/listinfo/doxygen-users

-- 
--
Exit Games | +49 40 413 596 0

Executive Christof Wegmann, CTO
Trade Registry / Amtsgericht Hamburg, Germany HRB 85991

We Make Multiplayer Simple | www.photonengine.com

[Doxygen-users] How can I add documentation for an inherited member function, that isn't overridden in the derived lass?

[Stefan L. <kai...@ex...>]

Hi.



I have the following situation:
class Base
{
public:
    doFoo(void);
};

class Derived : public Base
{
public:
    doBar(void);
};



Now I have documented Base::doFoo() and Derived::doBar(), but I need to
also document Derived::doFoo() with a doc that differs from the of
Base::doFoo(), although Derived does not override the implementation of
doFoo().
Is this possible? If yes, how?

/* @fn Derived::doFoo() */ makes Doxygen complain that it can't find a
matching class member for doFoo() in Derived.



Kind regards,
Stefan.

-- 
--
Exit Games | +49 40 413 596 0

Executive Christof Wegmann, CTO
Trade Registry / Amtsgericht Hamburg, Germany HRB 85991

We Make Multiplayer Simple | www.photonengine.com

[Doxygen-users] partial template specialization of the base class

[Denis D. <dav...@gm...>]

Dear all,

With have the following tricky case with partial template specialization.
Here is an example:

template <int dim, int n_components>
class Base
{
   void foo();
}

template <int dim>
class Base <dim,1>
{
   // some specific functions
  void bar();
}

template <int dim>
class Base <dim,dim>
{
   // some other specific functions
   void baz();
}


template <int dim, int n_components >
class Derived : public Base<dim,n_components>
{
}

The problem is that for “Derived” class "Public member functions inherited from Base”
only shows those in Base<dim,n_components> (i.e. “foo()”),
while there is no extra link to functions which would be available in partially specialised case of the Derived class, 
i.e. Derived<dim,1> will have bar() and Derived<dim,dim> will have baz().

Is there a way to make doxygen show/include functions in Derived coming from partial template specialization 
of Base class?

p.s. documentation for partial specialization of Base class works fine and is rendered correctly.

Regards,
Denis

Re: [Doxygen-users] PREDEFINES macro expansion without spaces

[Frank M. <fra...@gm...>]

Hi Albert,

thanks. I've just tried 1.8.13 and saw the same result. Therefore I filed a
bug report, see https://bugzilla.gnome.org/show_bug.cgi?id=777753 .

Kind regards,

Frank

On Mittwoch, 25. Januar 2017 15:46:39 CET Albert wrote:
> Frank,
> 
> What happens in the current version (1.8.13). when persistent add a minimal
> example showing the problem or file a bug report a bug report on bugzilla (
> https://bugzilla.gnome.org/enter_bug.cgi?product=doxygen) with a, minimal,
> self-contained example (source+config file in a tar or zip) that allows us
> to reproduce the problem.
> 
> Albert
> 
> On Wed, Jan 25, 2017 at 3:34 PM, Frank Mehnert <fra...@gm...>
> wrote:
> 
> > Hi,
> >
> > I define a macro like
> >
> >   "FOO(x)=virtual ~x();"
> >
> > to be able to create an empty virtual destructor of a C++ class. However,
> > the expanded text of
> >
> >   FOO(bar)
> >
> > is
> >
> >   ~  bar  ();
> >
> > Doxygen adds spaces before and after macro arguments which is not
> > appreciate
> > in cases like this because "~  bar" is not considered a destructor (at
> > least
> > not from Doxygen itself).
> >
> > Is there some reason to suppress adding these spaces?
> >
> > I'm using Doxygen 1.8.12.
> >
> > Thanks,
> >
> > Frank
> >
> > ------------------------------------------------------------
> > ------------------
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> > _______________________________________________
> > Doxygen-users mailing list
> > Dox...@li...
> > https://lists.sourceforge.net/lists/listinfo/doxygen-users
> >
> 


-- 
Dr.-Ing. Frank Mehnert | Software Development Director, VirtualBox
ORACLE Deutschland B.V. & Co. KG | Werkstr. 24 | 71384 Weinstadt, Germany

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstraße 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher

Re: [Doxygen-users] PREDEFINES macro expansion without spaces

[Albert <alb...@gm...>]

Frank,

What happens in the current version (1.8.13). when persistent add a minimal
example showing the problem or file a bug report a bug report on bugzilla (
https://bugzilla.gnome.org/enter_bug.cgi?product=doxygen) with a, minimal,
self-contained example (source+config file in a tar or zip) that allows us
to reproduce the problem.

Albert

On Wed, Jan 25, 2017 at 3:34 PM, Frank Mehnert <fra...@gm...>
wrote:

> Hi,
>
> I define a macro like
>
>   "FOO(x)=virtual ~x();"
>
> to be able to create an empty virtual destructor of a C++ class. However,
> the expanded text of
>
>   FOO(bar)
>
> is
>
>   ~  bar  ();
>
> Doxygen adds spaces before and after macro arguments which is not
> appreciate
> in cases like this because "~  bar" is not considered a destructor (at
> least
> not from Doxygen itself).
>
> Is there some reason to suppress adding these spaces?
>
> I'm using Doxygen 1.8.12.
>
> Thanks,
>
> Frank
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Doxygen-users mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-users
>

Re: [Doxygen-users] Problem with creating PDF from LaTEX

[Sascha M. <Sas...@ma...>]

Hi Albert,


On 25.01.2017 14:43, Albert wrote:
> Dear Sascha.
>
> It is of course not a good solution as you have to remove it every
> time you rebuild the documentation.
>
> Would be appreciated when a bug report would be filed on bugzilla
> (https://bugzilla.gnome.org/enter_bug.cgi?product=doxygen) with a,
> minimal, self-contained example (source+config file in a tar or zip)
> that allows us to reproduce the problem?
Its done: https://bugzilla.gnome.org/show_bug.cgi?id=777746

Greeting Sascha
-- 


<https://saigkill.github.io/>

Sascha Manns
Sas...@ma... <mailto:Sas...@ma...>
GPG: 0x168428cdb1f20ab1
<http://pgpkey.org/pks/lookup?op=vindex&search=0x168428cdb1f20ab1&fingerprint=on>
jabber:Sas...@ja... <jabber:Sas...@ja...>


Maifeldstraße 10
56727 Mayen
mobile: +49-1573-9242730
home: +49-2651-4014045
https://saigkill.github.io

Twitter <https://twitter.com/saigkill> Facebook
<https://www.facebook.com/sascha.manns> LinkedIn
<https://de.linkedin.com/in/saigkill> Skype <skype:schurik0815?call>
Github <https://github.com/saigkill> Xing
<https://www.xing.com/profile/Sascha_Manns4>

[Doxygen-users] PREDEFINES macro expansion without spaces

[Frank M. <fra...@gm...>]

Hi,

I define a macro like

  "FOO(x)=virtual ~x();"

to be able to create an empty virtual destructor of a C++ class. However,
the expanded text of

  FOO(bar)

is

  ~  bar  ();

Doxygen adds spaces before and after macro arguments which is not appreciate
in cases like this because "~  bar" is not considered a destructor (at least
not from Doxygen itself).

Is there some reason to suppress adding these spaces?

I'm using Doxygen 1.8.12.

Thanks,

Frank

Re: [Doxygen-users] Problem with creating PDF from LaTEX

[Albert <alb...@gm...>]

Rob,

This is here not the case, and normally should not occur either when you
encounter such a problem a bug report is appreciated. I removed the output
directory, regenerated the documentation and the problem still occurs as
doxygen writes again:
\begin{DoxyCompactItemize}
\end{DoxyCompactItemize}
in the file: namespace_publican_creators.tex

Albert

On Wed, Jan 25, 2017 at 2:48 PM, Robert Heller <he...@de...> wrote:

> Oh, you might need to do a make clean.  Sometimes cruft is left over and
> *LaTeX* is partitularly bad when dealing with leftover .aux files.
>
> My make statements for doxygen => latex => PDF look like:
>
>     -rm -rf latex
>     $(DOXYGEN)
>     $(MAKE) -C latex
>
>
>
> At Wed, 25 Jan 2017 11:59:05 +0100 Albert <alb...@gm...> wrote:
>
> >
> >
> >
> >
> > Which version of doxygen? Current version is 1.8.13.
> >
> > Albert
> >
> > On Wed, Jan 25, 2017 at 11:52 AM, Sascha Manns <Sas...@ma...
> >
> > wrote:
> >
> > > Hello list,
> > >
> > > actually i'm trying to get a PDF from LaTEX sources.
> > >
> > > I'm getting:
> > >
> > > [5] [6]
> > > Chapter 4.
> > > (./namespace_publican_creators.tex
> > >
> > > ! LaTeX Error: Something's wrong--perhaps a missing \item.
> > >
> > > See the LaTeX manual or LaTeX Companion for explanation.
> > > Type  H <return>  for immediate help.
> > >  ...
> > >
> > > l.5 \end{DoxyCompactItemize}
> > >
> > > The full Log can be viewed there: http://pastebin.com/QzWgZWb3
> > > The mentioned file is viewable there: https://github.com/saigkill/
> > > PublicanCreators/blob/master/docs/api/latex/namespace_
> > > publican_creators.tex
> > >
> > > Maybe anyone can help to locate the error?
> > > --
> > >
> > >
> > > <https://saigkill.github.io/>
> > >
> > > Sascha Manns
> > > Sas...@ma...
> > > GPG: 0x168428cdb1f20ab1
> > > <http://pgpkey.org/pks/lookup?op=vindex&search=0x168428cdb1f20ab1&
> fingerprint=on>
> > > jabber: Sas...@ja...
> > >
> > >
> > > Maifeldstraße 10
> > > 56727 Mayen
> > > mobile: +49-1573-9242730 <+49%201573%209242730>
> > > home: +49-2651-4014045 <+49%202651%204014045>
> > > https://saigkill.github.io
> > >
> > > [image: Twitter] <https://twitter.com/saigkill> [image: Facebook]
> > > <https://www.facebook.com/sascha.manns> [image: LinkedIn]
> > > <https://de.linkedin.com/in/saigkill> [image: Skype] [image: Github]
> > > <https://github.com/saigkill> [image: Xing]
> > > <https://www.xing.com/profile/Sascha_Manns4>
> > >
> > > ------------------------------------------------------------
> > > ------------------
> > > Check out the vibrant tech community on one of the world's most
> > > engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> > > _______________________________________________
> > > Doxygen-users mailing list
> > > Dox...@li...
> > > https://lists.sourceforge.net/lists/listinfo/doxygen-users
> > >
> > >
> > X-Attachment-Id: 89dd7d1599f3df7c_0.0.0.0.1.6
> >
> >
> > This message contains data in an unrecognized format, image/png,
> > which is being decoded and written to the file named "/home/heller/Mail/
> Attachments/1-github.png".
> > If you do not want this data, you probably should delete that file.
> > Wrote file /home/heller/Mail/Attachments/1-github.png
> > X-Attachment-Id: 89dd7d1599f3df7c_0.0.0.0.1.7
> >
> >
> > This message contains data in an unrecognized format, image/png,
> > which is being decoded and written to the file named "/home/heller/Mail/
> Attachments/1-xing.png".
> > If you do not want this data, you probably should delete that file.
> > Wrote file /home/heller/Mail/Attachments/1-xing.png
> > X-Attachment-Id: 89dd7d1599f3df7c_0.0.0.0.1.3
> >
> >
> > This message contains data in an unrecognized format, image/png,
> > which is being decoded and written to the file named "/home/heller/Mail/
> Attachments/1-facebook.png".
> > If you do not want this data, you probably should delete that file.
> > Wrote file /home/heller/Mail/Attachments/1-facebook.png
> > X-Attachment-Id: 89dd7d1599f3df7c_0.0.0.0.1.5
> >
> >
> > This message contains data in an unrecognized format, image/png,
> > which is being decoded and written to the file named "/home/heller/Mail/
> Attachments/1-skype.png".
> > If you do not want this data, you probably should delete that file.
> > Wrote file /home/heller/Mail/Attachments/1-skype.png
> > X-Attachment-Id: 89dd7d1599f3df7c_0.0.0.0.1.1
> >
> >
> > This message contains data in an unrecognized format, image/png,
> > which is being decoded and written to the file named "/home/heller/Mail/
> Attachments/1-twitter.png".
> > If you do not want this data, you probably should delete that file.
> > Wrote file /home/heller/Mail/Attachments/1-twitter.png
> > X-Attachment-Id: 89dd7d1599f3df7c_0.0.0.0.1.2
> >
> >
> > This message contains data in an unrecognized format, image/gif,
> > which is being decoded and written to the file named "/home/heller/Mail/
> Attachments/1-spacer.gif".
> > If you do not want this data, you probably should delete that file.
> > Wrote file /home/heller/Mail/Attachments/1-spacer.gif
> > X-Attachment-Id: 89dd7d1599f3df7c_0.0.0.0.1.4
> >
> >
> > This message contains data in an unrecognized format, image/png,
> > which is being decoded and written to the file named "/home/heller/Mail/
> Attachments/1-linkedin.png".
> > If you do not want this data, you probably should delete that file.
> > Wrote file /home/heller/Mail/Attachments/1-linkedin.png
> > MIME-Version: 1.0
> >
> > ------------------------------------------------------------
> ------------------
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> > MIME-Version: 1.0
> >
> > _______________________________________________
> > Doxygen-users mailing list
> > Dox...@li...
> > https://lists.sourceforge.net/lists/listinfo/doxygen-users
> >
> >
>
> --
> Robert Heller             -- 978-544-6933
> Deepwoods Software        -- Custom Software Services
> http://www.deepsoft.com/  -- Linux Administration Services
> he...@de...       -- Webhosting Services
>
>

Re: [Doxygen-users] Problem with creating PDF from LaTEX

[Robert H. <he...@de...>]

Oh, you might need to do a make clean.  Sometimes cruft is left over and 
*LaTeX* is partitularly bad when dealing with leftover .aux files.

My make statements for doxygen => latex => PDF look like:

    -rm -rf latex
    $(DOXYGEN)
    $(MAKE) -C latex



At Wed, 25 Jan 2017 11:59:05 +0100 Albert <alb...@gm...> wrote:

> 
> 
> 
> 
> Which version of doxygen? Current version is 1.8.13.
> 
> Albert
> 
> On Wed, Jan 25, 2017 at 11:52 AM, Sascha Manns <Sas...@ma...>
> wrote:
> 
> > Hello list,
> >
> > actually i'm trying to get a PDF from LaTEX sources.
> >
> > I'm getting:
> >
> > [5] [6]
> > Chapter 4.
> > (./namespace_publican_creators.tex
> >
> > ! LaTeX Error: Something's wrong--perhaps a missing \item.
> >
> > See the LaTeX manual or LaTeX Companion for explanation.
> > Type  H <return>  for immediate help.
> >  ...
> >
> > l.5 \end{DoxyCompactItemize}
> >
> > The full Log can be viewed there: http://pastebin.com/QzWgZWb3
> > The mentioned file is viewable there: https://github.com/saigkill/
> > PublicanCreators/blob/master/docs/api/latex/namespace_
> > publican_creators.tex
> >
> > Maybe anyone can help to locate the error?
> > --
> >
> >
> > <https://saigkill.github.io/>
> >
> > Sascha Manns
> > Sas...@ma...
> > GPG: 0x168428cdb1f20ab1
> > <http://pgpkey.org/pks/lookup?op=vindex&search=0x168428cdb1f20ab1&fingerprint=on>
> > jabber: Sas...@ja...
> >
> >
> > Maifeldstraße 10
> > 56727 Mayen
> > mobile: +49-1573-9242730 <+49%201573%209242730>
> > home: +49-2651-4014045 <+49%202651%204014045>
> > https://saigkill.github.io
> >
> > [image: Twitter] <https://twitter.com/saigkill> [image: Facebook]
> > <https://www.facebook.com/sascha.manns> [image: LinkedIn]
> > <https://de.linkedin.com/in/saigkill> [image: Skype] [image: Github]
> > <https://github.com/saigkill> [image: Xing]
> > <https://www.xing.com/profile/Sascha_Manns4>
> >
> > ------------------------------------------------------------
> > ------------------
> > Check out the vibrant tech community on one of the world's most
> > engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> > _______________________________________________
> > Doxygen-users mailing list
> > Dox...@li...
> > https://lists.sourceforge.net/lists/listinfo/doxygen-users
> >
> >
> X-Attachment-Id: 89dd7d1599f3df7c_0.0.0.0.1.6
> 
> 
> This message contains data in an unrecognized format, image/png,
> which is being decoded and written to the file named "/home/heller/Mail/Attachments/1-github.png".
> If you do not want this data, you probably should delete that file.
> Wrote file /home/heller/Mail/Attachments/1-github.png
> X-Attachment-Id: 89dd7d1599f3df7c_0.0.0.0.1.7
> 
> 
> This message contains data in an unrecognized format, image/png,
> which is being decoded and written to the file named "/home/heller/Mail/Attachments/1-xing.png".
> If you do not want this data, you probably should delete that file.
> Wrote file /home/heller/Mail/Attachments/1-xing.png
> X-Attachment-Id: 89dd7d1599f3df7c_0.0.0.0.1.3
> 
> 
> This message contains data in an unrecognized format, image/png,
> which is being decoded and written to the file named "/home/heller/Mail/Attachments/1-facebook.png".
> If you do not want this data, you probably should delete that file.
> Wrote file /home/heller/Mail/Attachments/1-facebook.png
> X-Attachment-Id: 89dd7d1599f3df7c_0.0.0.0.1.5
> 
> 
> This message contains data in an unrecognized format, image/png,
> which is being decoded and written to the file named "/home/heller/Mail/Attachments/1-skype.png".
> If you do not want this data, you probably should delete that file.
> Wrote file /home/heller/Mail/Attachments/1-skype.png
> X-Attachment-Id: 89dd7d1599f3df7c_0.0.0.0.1.1
> 
> 
> This message contains data in an unrecognized format, image/png,
> which is being decoded and written to the file named "/home/heller/Mail/Attachments/1-twitter.png".
> If you do not want this data, you probably should delete that file.
> Wrote file /home/heller/Mail/Attachments/1-twitter.png
> X-Attachment-Id: 89dd7d1599f3df7c_0.0.0.0.1.2
> 
> 
> This message contains data in an unrecognized format, image/gif,
> which is being decoded and written to the file named "/home/heller/Mail/Attachments/1-spacer.gif".
> If you do not want this data, you probably should delete that file.
> Wrote file /home/heller/Mail/Attachments/1-spacer.gif
> X-Attachment-Id: 89dd7d1599f3df7c_0.0.0.0.1.4
> 
> 
> This message contains data in an unrecognized format, image/png,
> which is being decoded and written to the file named "/home/heller/Mail/Attachments/1-linkedin.png".
> If you do not want this data, you probably should delete that file.
> Wrote file /home/heller/Mail/Attachments/1-linkedin.png
> MIME-Version: 1.0
> 
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> MIME-Version: 1.0
> 
> _______________________________________________
> Doxygen-users mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-users
> 
>                                                                                                                      

-- 
Robert Heller             -- 978-544-6933
Deepwoods Software        -- Custom Software Services
http://www.deepsoft.com/  -- Linux Administration Services
he...@de...       -- Webhosting Services
                   

Re: [Doxygen-users] Problem with creating PDF from LaTEX

[Albert <alb...@gm...>]

Dear Sascha.

It is of course not a good solution as you have to remove it every time you
rebuild the documentation.

Would be appreciated when a bug report would be filed on bugzilla (
https://bugzilla.gnome.org/enter_bug.cgi?product=doxygen) with a, minimal,
self-contained example (source+config file in a tar or zip) that allows us
to reproduce the problem?

Albert

On Wed, Jan 25, 2017 at 2:37 PM, Sascha Manns <Sas...@ma...>
wrote:

> Hi Albert,
>
> On 25.01.2017 14:21, Albert wrote:
>
> In the file namespace_publican_creators.tex I found under the
> \subsection*{Namespaces} :
> \begin{DoxyCompactItemize}
> \end{DoxyCompactItemize}
>
> So an empty list and this causes, apparently, the problem. When removing
> these 2 lines the document builds.
>
> I don't know the reason for this empty list.
>
> I tried it out, and after removing the mentioned lines it builds perfectly.
>
> Thank you very much :-)
> --
>
>
> <https://saigkill.github.io/>
>
> Sascha Manns
> Sas...@ma...
> GPG: 0x168428cdb1f20ab1
> <http://pgpkey.org/pks/lookup?op=vindex&search=0x168428cdb1f20ab1&fingerprint=on>
> jabber: Sas...@ja...
>
>
> Maifeldstraße 10
> 56727 Mayen
> mobile: +49-1573-9242730 <+49%201573%209242730>
> home: +49-2651-4014045 <+49%202651%204014045>
> https://saigkill.github.io
>
> [image: Twitter] <https://twitter.com/saigkill> [image: Facebook]
> <https://www.facebook.com/sascha.manns> [image: LinkedIn]
> <https://de.linkedin.com/in/saigkill> [image: Skype] [image: Github]
> <https://github.com/saigkill> [image: Xing]
> <https://www.xing.com/profile/Sascha_Manns4>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Doxygen-users mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-users
>
>

Re: [Doxygen-users] Problem with creating PDF from LaTEX

[Sascha M. <Sas...@ma...>]

Hi Albert,


On 25.01.2017 14:21, Albert wrote:
> In the file namespace_publican_creators.tex I found under the
> \subsection*{Namespaces} :
> \begin{DoxyCompactItemize}
> \end{DoxyCompactItemize}
>
> So an empty list and this causes, apparently, the problem. When
> removing these 2 lines the document builds.
>
> I don't know the reason for this empty list.
I tried it out, and after removing the mentioned lines it builds perfectly.

Thank you very much :-)
-- 


<https://saigkill.github.io/>

Sascha Manns
Sas...@ma... <mailto:Sas...@ma...>
GPG: 0x168428cdb1f20ab1
<http://pgpkey.org/pks/lookup?op=vindex&search=0x168428cdb1f20ab1&fingerprint=on>
jabber:Sas...@ja... <jabber:Sas...@ja...>


Maifeldstraße 10
56727 Mayen
mobile: +49-1573-9242730
home: +49-2651-4014045
https://saigkill.github.io

Twitter <https://twitter.com/saigkill> Facebook
<https://www.facebook.com/sascha.manns> LinkedIn
<https://de.linkedin.com/in/saigkill> Skype <skype:schurik0815?call>
Github <https://github.com/saigkill> Xing
<https://www.xing.com/profile/Sascha_Manns4>

Re: [Doxygen-users] Problem with creating PDF from LaTEX

[Albert <alb...@gm...>]

In the file namespace_publican_creators.tex I found under the
\subsection*{Namespaces} :
\begin{DoxyCompactItemize}
\end{DoxyCompactItemize}

So an empty list and this causes, apparently, the problem. When removing
these 2 lines the document builds.

I don't know the reason for this empty list.


Albert

On Wed, Jan 25, 2017 at 1:59 PM, Albert <alb...@gm...> wrote:

> I tried it with the 1.8.13 after downloading the source code from github
> and get the same error.
> (would be good when the project logo would be in the repository as well
> and not taken from /home/....)
>
> Albert
>
> On Wed, Jan 25, 2017 at 1:47 PM, Sascha Manns <Sas...@ma...>
> wrote:
>
>> Hi Albert,
>>
>> On 25.01.2017 11:59, Albert wrote:
>>
>> Which version of doxygen? Current version is 1.8.13.
>>
>> Albert
>>
>> i'm using a 1.8.13 on a Ubuntu Backport.
>>
>> --
>>
>>
>> <https://saigkill.github.io/>
>>
>> Sascha Manns
>> Sas...@ma...
>> GPG: 0x168428cdb1f20ab1
>> <http://pgpkey.org/pks/lookup?op=vindex&search=0x168428cdb1f20ab1&fingerprint=on>
>> jabber: Sas...@ja...
>>
>>
>> Maifeldstraße 10
>> 56727 Mayen
>> mobile: +49-1573-9242730 <+49%201573%209242730>
>> home: +49-2651-4014045 <+49%202651%204014045>
>> https://saigkill.github.io
>>
>> [image: Twitter] <https://twitter.com/saigkill> [image: Facebook]
>> <https://www.facebook.com/sascha.manns> [image: LinkedIn]
>> <https://de.linkedin.com/in/saigkill> [image: Skype] [image: Github]
>> <https://github.com/saigkill> [image: Xing]
>> <https://www.xing.com/profile/Sascha_Manns4>
>>
>> ------------------------------------------------------------
>> ------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Doxygen-users mailing list
>> Dox...@li...
>> https://lists.sourceforge.net/lists/listinfo/doxygen-users
>>
>>
>

Re: [Doxygen-users] Problem with creating PDF from LaTEX

[Albert <alb...@gm...>]

I tried it with the 1.8.13 after downloading the source code from github
and get the same error.
(would be good when the project logo would be in the repository as well and
not taken from /home/....)

Albert

On Wed, Jan 25, 2017 at 1:47 PM, Sascha Manns <Sas...@ma...>
wrote:

> Hi Albert,
>
> On 25.01.2017 11:59, Albert wrote:
>
> Which version of doxygen? Current version is 1.8.13.
>
> Albert
>
> i'm using a 1.8.13 on a Ubuntu Backport.
>
> --
>
>
> <https://saigkill.github.io/>
>
> Sascha Manns
> Sas...@ma...
> GPG: 0x168428cdb1f20ab1
> <http://pgpkey.org/pks/lookup?op=vindex&search=0x168428cdb1f20ab1&fingerprint=on>
> jabber: Sas...@ja...
>
>
> Maifeldstraße 10
> 56727 Mayen
> mobile: +49-1573-9242730 <+49%201573%209242730>
> home: +49-2651-4014045 <+49%202651%204014045>
> https://saigkill.github.io
>
> [image: Twitter] <https://twitter.com/saigkill> [image: Facebook]
> <https://www.facebook.com/sascha.manns> [image: LinkedIn]
> <https://de.linkedin.com/in/saigkill> [image: Skype] [image: Github]
> <https://github.com/saigkill> [image: Xing]
> <https://www.xing.com/profile/Sascha_Manns4>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Doxygen-users mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-users
>
>

Re: [Doxygen-users] Problem with creating PDF from LaTEX

[Sascha M. <Sas...@ma...>]

Hi Albert,


On 25.01.2017 11:59, Albert wrote:
> Which version of doxygen? Current version is 1.8.13.
>
> Albert
i'm using a 1.8.13 on a Ubuntu Backport.

-- 


<https://saigkill.github.io/>

Sascha Manns
Sas...@ma... <mailto:Sas...@ma...>
GPG: 0x168428cdb1f20ab1
<http://pgpkey.org/pks/lookup?op=vindex&search=0x168428cdb1f20ab1&fingerprint=on>
jabber:Sas...@ja... <jabber:Sas...@ja...>


Maifeldstraße 10
56727 Mayen
mobile: +49-1573-9242730
home: +49-2651-4014045
https://saigkill.github.io

Twitter <https://twitter.com/saigkill> Facebook
<https://www.facebook.com/sascha.manns> LinkedIn
<https://de.linkedin.com/in/saigkill> Skype <skype:schurik0815?call>
Github <https://github.com/saigkill> Xing
<https://www.xing.com/profile/Sascha_Manns4>

Re: [Doxygen-users] Problem with creating PDF from LaTEX

[Albert <alb...@gm...>]

Which version of doxygen? Current version is 1.8.13.

Albert

On Wed, Jan 25, 2017 at 11:52 AM, Sascha Manns <Sas...@ma...>
wrote:

> Hello list,
>
> actually i'm trying to get a PDF from LaTEX sources.
>
> I'm getting:
>
> [5] [6]
> Chapter 4.
> (./namespace_publican_creators.tex
>
> ! LaTeX Error: Something's wrong--perhaps a missing \item.
>
> See the LaTeX manual or LaTeX Companion for explanation.
> Type  H <return>  for immediate help.
>  ...
>
> l.5 \end{DoxyCompactItemize}
>
> The full Log can be viewed there: http://pastebin.com/QzWgZWb3
> The mentioned file is viewable there: https://github.com/saigkill/
> PublicanCreators/blob/master/docs/api/latex/namespace_
> publican_creators.tex
>
> Maybe anyone can help to locate the error?
> --
>
>
> <https://saigkill.github.io/>
>
> Sascha Manns
> Sas...@ma...
> GPG: 0x168428cdb1f20ab1
> <http://pgpkey.org/pks/lookup?op=vindex&search=0x168428cdb1f20ab1&fingerprint=on>
> jabber: Sas...@ja...
>
>
> Maifeldstraße 10
> 56727 Mayen
> mobile: +49-1573-9242730 <+49%201573%209242730>
> home: +49-2651-4014045 <+49%202651%204014045>
> https://saigkill.github.io
>
> [image: Twitter] <https://twitter.com/saigkill> [image: Facebook]
> <https://www.facebook.com/sascha.manns> [image: LinkedIn]
> <https://de.linkedin.com/in/saigkill> [image: Skype] [image: Github]
> <https://github.com/saigkill> [image: Xing]
> <https://www.xing.com/profile/Sascha_Manns4>
>
> ------------------------------------------------------------
> ------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Doxygen-users mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-users
>
>

[Doxygen-users] Problem with creating PDF from LaTEX

[Sascha M. <Sas...@ma...>]

Hello list,

actually i'm trying to get a PDF from LaTEX sources.

I'm getting:

[5] [6]
Chapter 4.
(./namespace_publican_creators.tex

! LaTeX Error: Something's wrong--perhaps a missing \item.

See the LaTeX manual or LaTeX Companion for explanation.
Type  H <return>  for immediate help.
 ...                                             
                                                 
l.5 \end{DoxyCompactItemize}

The full Log can be viewed there: http://pastebin.com/QzWgZWb3
The mentioned file is viewable there:
https://github.com/saigkill/PublicanCreators/blob/master/docs/api/latex/namespace_publican_creators.tex

Maybe anyone can help to locate the error?
-- 


<https://saigkill.github.io/>

Sascha Manns
Sas...@ma... <mailto:Sas...@ma...>
GPG: 0x168428cdb1f20ab1
<http://pgpkey.org/pks/lookup?op=vindex&search=0x168428cdb1f20ab1&fingerprint=on>
jabber:Sas...@ja... <jabber:Sas...@ja...>


Maifeldstraße 10
56727 Mayen
mobile: +49-1573-9242730
home: +49-2651-4014045
https://saigkill.github.io

Twitter <https://twitter.com/saigkill> Facebook
<https://www.facebook.com/sascha.manns> LinkedIn
<https://de.linkedin.com/in/saigkill> Skype <skype:schurik0815?call>
Github <https://github.com/saigkill> Xing
<https://www.xing.com/profile/Sascha_Manns4>

[Doxygen-users] Unexpected tag `anchor` found in struct compound in tagfile

[John G. <jg....@gm...>]

I am using Doxygen in two packages, with one using a tagfile generated by
the other.

I get the following warning when building the package (which depends on the
other) :

doxygen.tag:2342: warning: Unexpected tag `anchor' found
(repeated AFAIK each time there's an anchor tag inside a struct compound
tag)

This only appears to concern anchor tags inside struct compound tags.

The C code which defines the structs is similar to :

    /**
     * An error
     */
    struct err_s {
        size_t err_nb;
        size_t * err_msg;
    };

    /**
     * Alias
     */
    typedef struct err_s err_s;

Hope this is enough information to fix the warning or generation of
incorrect tags, whichever needs to be fixed.


Thanks !
-- 
John Gliksberg
M2 MIHPS @ UVSQ
mobile : +33.6.40.60.76.95

[Doxygen-users] namespace members varying behaviour on Doxygen 1.8.10

[didje <dia...@pd...>]

I generate doxygen documentation in Linux and Windows. However, there is a
difference in the "Namespace Members" section between the resulting
generated documentation.

In the generated Linux documentation:
- In the "Namespace Members" section, in the "All" tab, when I click on the
letter "a", the displayed page is named as follows:
namespacemembers.html
- In the "Namespace Members" section, in the "All" tab, when I click on the
letter "e", the displayed page is named as follows:
namespacemembers_e.html
The same goes for any other letters I click on, so when I click on the
letter "g", the displayed page is: namespacemembers_g.html

In the generated Windows documentation:
- In the "Namespace Members" section, in the "All" tab, when I click on the
letter "a", the displayed page is named as follows:
namespacemembers.html#index_a
- In the "Namespace Members" section, in the "All" tab, when I click on the
letter "e", the displayed page is named as follows:
namespacemembers.html#index_e
The same goes for any other letters I click on, so when I click on the
letter "g", the displayed page is: namespacemembers.html#index_g

In other words, in Linux, there is a new page created for every namespace
member alphabetic list, whereas in Windows, there is a single page 
created consisting of all the namespace members, organised by alphabetic
list. 

My question is: is this decided by some property in the Doxyfile and, if so,
by which one ?

As far as I am aware, the Linux documentation and the Windows documentation
is generated using the same Doxyfile, however, I am starting to doubt this
based on the different results on the generated documentation in each
platform.








--
View this message in context: http://doxygen.10944.n7.nabble.com/namespace-members-varying-behaviour-on-Doxygen-1-8-10-tp7776.html
Sent from the Doxygen - Users mailing list archive at Nabble.com.

[Doxygen-users] Announce: Doxygen PLugin for Gradle 0.3 released

[Schalk C. <ys...@gm...>]

Hi all,


I'm happy to announce the v0.3 for Doxygen support in Gradle has been 
released with the following key feature:

- On Linux, MacOsX and WIndows it is no longer required to have Doxygen 
installed.  If only a version is specified Gradle will download, unpack 
and cache it locally. This could be very useful especially on CI servers.

- Anyone using Gradle elsewhere (which is rare) will still need to have 
Doxygen in path or specify a fixed path in Gradle script.


Other smaller changes include:

- Deprecated XML_SCHEMA, XML_DTD removed from template Doxyfile.

- Minimum of JDK7 is required to run.

- The Doxyfile parser has been fixed to allow backslash continuations.


As always feedback is appreciated and issues can be raised on Github: 
https://github.com/ysb33r/doxygen-gradle-plugin

-- 
Schalk W. Cronjé
Twitter / Ello / Toeter : @ysb33r

[Doxygen-users] C# 'using' with '=' results in "was not declared or defined"

[Brier, Frederick(GE O. & Gas) <Fre...@ge...>]

Some C# code has syntax of the variety:

using AbbrSym = com.mycompany.templateclass<item>;

causes Doxygen to issue a warning: documented symbol `typedef com mycompany template class<item> AbbrSym' was not declared or defined.

Is this a language feature that has not been implemented?  Or is there a workaround?  I suspect that these "undefined" symbols are responsible for my class inheritance and diagrams from not showing up.  Thank you.

Re: [Doxygen-users] Doxygen first use

[First L. <ber...@gm...>]

In pdf generation in latex the error is :

! LaTeX Error: File `files.tex' not found.

Type X to quit or <RETURN> to proceed,
or enter new name. (Default extension: tex)

Enter file name:....

On Tue, Dec 13, 2016 at 5:37 PM, First Last <ber...@gm...> wrote:

> Hello,
>
> Thanks for Doxygen, this is very useful.
>
> I was testing version 1.8.12 in windows on a small C# project and it was
> working fine.
>
> If i may suggest, just add at the end of the wizard log that i have to go
> in latex folder with a command tool and execute "make pdf" to generate the
> pdf doc :-)
>
> After i have tried Doxygen on a larger folder i have to analyse, it did
> some work. But the html doc is not working normally, as the first page
> misses the index, and files "files.html" and "globals.html" are missing.
> Also the latex pdf generation is not working.
>
> But there is NO visible error in the wizard log. What is happening ? I
> imagine the project i want to document is bigger than what Doxygen can
> handle, but would it be possible to have a clear error message ?
>
> I may suggest also :
>
> - that all warning messages in Doxygen logs would be written in each file
> page as "analysis error", instead of having to dig inside thousands lines
> to find warnings.
>
> - And that all Doxygen errors have a specific format so that a simple
> search can find them, like \error or ***error for instance.
>
>
> This is a fisrt user view, keeping in mind that this documentation
> generation software is unique :-) so thanks to all authors ! Suggestioons
> in theis emails are only to help improve it form a "first user" point of
> view.
>
> Also i would suggest a hierachical proggression option in the wizard :
> - first producing a high level document with the list of projects,
> - then a document for each project,
> - and finally a document of project inter-calling hierarchy : which
> project calls which projects and reciprocally.
>
> Best regards,
> Bernard
>

[Doxygen-users] Doxygen first use

[First L. <ber...@gm...>]

Hello,

Thanks for Doxygen, this is very useful.

I was testing version 1.8.12 in windows on a small C# project and it was
working fine.

If i may suggest, just add at the end of the wizard log that i have to go
in latex folder with a command tool and execute "make pdf" to generate the
pdf doc :-)

After i have tried Doxygen on a larger folder i have to analyse, it did
some work. But the html doc is not working normally, as the first page
misses the index, and files "files.html" and "globals.html" are missing.
Also the latex pdf generation is not working.

But there is NO visible error in the wizard log. What is happening ? I
imagine the project i want to document is bigger than what Doxygen can
handle, but would it be possible to have a clear error message ?

I may suggest also :

- that all warning messages in Doxygen logs would be written in each file
page as "analysis error", instead of having to dig inside thousands lines
to find warnings.

- And that all Doxygen errors have a specific format so that a simple
search can find them, like \error or ***error for instance.


This is a fisrt user view, keeping in mind that this documentation
generation software is unique :-) so thanks to all authors ! Suggestioons
in theis emails are only to help improve it form a "first user" point of
view.

Also i would suggest a hierachical proggression option in the wizard :
- first producing a high level document with the list of projects,
- then a document for each project,
- and finally a document of project inter-calling hierarchy : which project
calls which projects and reciprocally.

Best regards,
Bernard

Re: [Doxygen-users] Documentation for typedefs not generated, C++ code

[Dimitri v. H. <do...@gm...>]

Hi Sam,

See this FAQ: http://www.doxygen.org/manual/faq.html#faq_extract_all

Regards,
  Dimitri

> On 07 Dec 2016, at 18:04 , Sam Varshavchik <mr...@co...> wrote:
> 
> With doxygen-1.8.12, in an otherwise empty directory:
> 
> $ doxygen -g
> 
> 
> Configuration file `Doxyfile' created.
> 
> Now edit the configuration file and enter
> 
> doxygen Doxyfile
> 
> to generate the documentation for your project
> 
> $ cat >foo.hh
> 
> //! A documented typedef
> 
> typedef int zz;
> [mrsam@octopus zz]$ doxygen
> Searching for include files..
> 
> The resulting documentation in the html directory is empty. The typedef is not documented. The generated documentation does have a "Files" section, that dutifully includes the foo.hh file, showing the typedef inside it, but with the doxygen comment block removed.
> 
> Replacing the typedef with "class zz{};" results in the expected output.
> 
> I must be missing something obvious.
> ------------------------------------------------------------------------------
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today.http://sdm.link/xeonphi_______________________________________________
> Doxygen-users mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-users

[Doxygen-users] Documentation for typedefs not generated, C++ code

[Sam V. <mr...@co...>]

With doxygen-1.8.12, in an otherwise empty directory:

$ doxygen -g


Configuration file `Doxyfile' created.

Now edit the configuration file and enter

  doxygen Doxyfile

to generate the documentation for your project

$ cat >foo.hh

//! A documented typedef

typedef int zz;
[mrsam@octopus zz]$ doxygen
Searching for include files..

The resulting documentation in the html directory is empty. The typedef is  
not documented. The generated documentation does have a "Files" section,  
that dutifully includes the foo.hh file, showing the typedef inside it, but  
with the doxygen comment block removed.

Replacing the typedef with "class zz{};" results in the expected output.

I must be missing something obvious.