doxygen-users — List for users of doxygen

[Doxygen-users] Windows binaries available for 1.8.8-20140924 at SourceForge

[Petr P. <Pr...@sk...>]

Hi,

If interested, you can download the doxygen binaries
compiled for MS Windows from

  http://sourceforge.net/projects/doxygen/files/snapshots/doxygen-1.8-svn/windows

This is the place where you should find also the next
releases.  Name of the archive file is

  doxygenw20140924_1_8_8.zip

The related translator report can be found inside the directory

  http://sourceforge.net/projects/doxygen/files/snapshots/doxygen-1.8-svn/translator_reports/

Name of the archive file is

  tr20140924_1_8_8.zip

The binaries are NOT created automatically, so it may
happen that some newer sources were not compiled
because I am not present to do that or I forgot... ;)

Regards,
    Petr

--
Petr Prikryl (prikryl at atlas dot cz)

Re: [Doxygen-users] Tag file missing public class members

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

On 23 Sep 2014, at 18:51 , Jeffrey Melville <jme...@mi...> wrote:
> 
> Dimitri,
> 
> Thanks for the update. Can you keep me in the loop on this feature?  I 
> would be happy to test out any commits for you against my codebase. I'm 
> going to continue using the workaround in the meantime.


Yes, please try the latest snapshot from GitHub which contains this commit:
https://github.com/doxygen/doxygen/commit/b9ad9a03cf4febeb2aa10ddca22c1c9296c5223b
and let me know if you still see any issues.

Regards,
  Dimitri

Re: [Doxygen-users] Tag file missing public class members

[Jeffrey M. <jme...@mi...>]

On 9/21/2014 3:14 PM, Dimitri van Heesch wrote:
> Hi David,
>
> Thanks for the reminder.
> I'm working on a different way to generate the tag files, i.e. using a separate function rather than to generate it as the side-effect of writing the documentation. That way the workaround with the 'tagDataWritten' flag is no longer needed.
>
> Regards,
>    Dimitri
>
> On 20 Sep 2014, at 3:43 , David Thompson <dav...@ki...> wrote:
>
>> Hi all,
>>
>> I just wanted to make sure that Jeffrey Melville's patch doesn't get dropped; I was having the same issue (no tag entry for a base class member when a subclass also documented it) and his patch got the tag file working for me.
>>
>> 	Thanks,
>> 	David
>>
>>> Below is a patch that fixed the problem on my codebase. I'm not sure if
>>> it breaks other cases where you actually want to suppress the tag data
>>> being generated multiple times. I can submit a Github pull request if
>>> you'd prefer.
>>>
>>> Cheers,
>>> Jeff
>>>
>>>  From b874223b33d4939c53b42df75ce62bcc4acea318 Mon Sep 17 00:00:00 2001
>>> From: Jeffrey Melville <jmelville@...>
>>> Date: Mon, 8 Sep 2014 13:16:29 -0400
>>> Subject: [PATCH] Fix for missing inherited class members in tag files.
>>>
>>> Signed-off-by: Jeffrey Melville <jmelville@...>
>>> ---
>>>   src/memberdef.cpp | 6 +++++-
>>>   1 file changed, 5 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/src/memberdef.cpp b/src/memberdef.cpp
>>> index a25528a..8626e5e 100644
>>> --- a/src/memberdef.cpp
>>> +++ b/src/memberdef.cpp
>>> @@ -3550,7 +3550,11 @@ Specifier MemberDef::virtualness(int count) const
>>>   void MemberDef::_writeTagData(const DefType compoundType)
>>>   {
>>>     unsigned typeMask = 1 << compoundType;
>>> -  if ((m_impl->tagDataWritten) & typeMask) return; // member already written for this type
>>> +
>>> +  // Return if member already written for this compoundType, except if
>>> +  // compoundType is a class. This function can be run multiple times for
>>> +  // classes in an inheritance hierarchy.
>>> +  if (compoundType != TypeClass && (m_impl->tagDataWritten) & typeMask) return;
>>>     if (m_impl->mtype==MemberType_EnumValue && m_impl->enumScope &&
>>>         m_impl->enumScope->isStrong()) return; // enum value is part of enum
>>>     static bool generateTagFile = !Config_getString("GENERATE_TAGFILE").isEmpty();
>>> --
>>> 1.9.1
>>
>> ------------------------------------------------------------------------------
>> Slashdot TV.  Video for Nerds.  Stuff that Matters.
>> http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Doxygen-users mailing list
>> Dox...@li...
>> https://lists.sourceforge.net/lists/listinfo/doxygen-users
>
>
> ------------------------------------------------------------------------------
> Slashdot TV.  Video for Nerds.  Stuff that Matters.
> http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
> _______________________________________________
> Doxygen-users mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-users
>

Dimitri,

Thanks for the update. Can you keep me in the loop on this feature?  I 
would be happy to test out any commits for you against my codebase. I'm 
going to continue using the workaround in the meantime.

Cheers,
Jeff

[Doxygen-users] Inheritance by non-documented classes

[Sebastien L. <slo...@gm...>]

Hi,

I have the following example:

    /// this class is documented
    struct documented{};

    struct hidden : public documented {};

setting HIDE_UNDOC_CLASSES     = YES

Then in the documentation page of `documented` I can see:

    Inherited by hidden.

Is it expected or is it a bug?
Tested with 2eece646.


Thanks,

Sebastien.

[Doxygen-users] Java: Annotations prevent Doxygen from documenting class (completely)

[starfuryAll <mar...@al...>]

Hi!

I'm new to Doxygen, installed 1.8.8 only today trying to create documenation
of my project.
Unfortunately I already came across a problem which seems to be a bug. Or I
just wasn't able to find a documented solution. Please forgive me if the
latter is the case, and thanks for any hints.

The problem I came across is similar to the problem described in the forum
post " Possible bug while producing documentation of java method which uses
generics
<http://doxygen.10944.n7.nabble.com/Possible-bug-while-producing-documentation-of-java-method-which-uses-generics-td6781.html> 
" only with the difference that it isn't related to generics but to
annotations.

Annotated Class

If a java class is annotated, Doxygen does not produce any class
documenation or index entry for that class. (Although, it is listed in the
'File list'.)

The "@SuppressWarnings" annotation here was only used to illustrate the
problem, it occurs with other (custom) annotations as well. For a reason
unknown to me the problem does /not/ occur with the "@Deprecated"
annotation.

Annotated Method

If a method is annotated Doxygen does create class documenation up until the
the method with the annotation. The annotated method all methods thereafter
are missing in the output.

Again, the "@SuppressWarnings" annotation here was only used to illustrate
the problem, it occurs with other (custom) annotations as well.


Without annotations the output looks like expected.

I also attach my .doxyfile to review the generator settings:  test.doxyfile
<http://doxygen.10944.n7.nabble.com/file/n6802/test.doxyfile>  


Thanks in advance for confirmation, any hints or even better a fix! ;-)

Markus



--
View this message in context: http://doxygen.10944.n7.nabble.com/Java-Annotations-prevent-Doxygen-from-documenting-class-completely-tp6802.html
Sent from the Doxygen - Users mailing list archive at Nabble.com.

Re: [Doxygen-users] Crash building class list

[David T. <dav...@ki...>]

Hi Dmitri,

> I would expect that this commit already addresses the problem below:
> https://github.com/doxygen/doxygen/commit/6d4044ad43ae1424a256eb1c26992301e7c64f4a

Yup, I have verified that it does. Thanks!

	David

> On 20 Sep 2014, at 3:58 , David Thompson <dav...@ki...> wrote:
> 
>> Hi all,
>> 
>> I have succeeded in crashing doxygen 1.8.8; it happens when I use a tag file for the Google sparsehash package in documentation for my own software. When I remove the sparsehash entry from the TAGFILES list, then the documentation builds properly. I've traced the crash to the "Building class list..." phase, where Definition::localName() is called with a NULL Definition*. The full stacktrace is below.
>> 
>> The problem appears to be in buildScopeFromQualifiedName() at line 1041 of doxygen.cpp, where a NULL innerScope variable is passed to
>> 
>> 	prevScope->addInnerCompound(innerScope);
>> 
>> The name parameter and fullScope variable are both "google::has_trivial_constructor< std::pair< T, U > >", i = 1, nsName = "has_trivial_constructor< std::pair< T, U > >", nd = 0, and cd = 0.
>> 
>> I am happy to try out patches and run things through the debugger, but don't have time to read more of the code. Does anyone have ideas for a fix?
>> 
>> 	Thanks,
>> 	David
>> 
>> Stack trace:
>> 
>> * thread #1: tid = 0x2464d42, 0x00000001000ac593 doxygen`Definition::localName(this=0x0000000000000000) const + 19 at definition.cpp:1386, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x8)
>> * frame #0: 0x00000001000ac593 doxygen`Definition::localName(this=0x0000000000000000) const + 19 at definition.cpp:1386
>>   frame #1: 0x0000000100380863 doxygen`NamespaceDef::addInnerCompound(this=0x0000000103e07500, d=0x0000000000000000) + 51 at namespacedef.cpp:136
>>   frame #2: 0x0000000100165fd1 doxygen`buildScopeFromQualifiedName(name=<unavailable>, level=2, lang=SrcLangExt_Unknown, tagInfo=0x00000001016d6e20) + 1537 at doxygen.cpp:1041
>>   frame #3: 0x00000001001822c4 doxygen`addClassToContext(rootNav=0x0000000102a4a0f0) + 2052 at doxygen.cpp:1315
>>   frame #4: 0x00000001001494db doxygen`buildClassList(rootNav=0x0000000102a4a0f0) + 91 at doxygen.cpp:1392
>>   frame #5: 0x0000000100149547 doxygen`buildClassList(rootNav=0x0000000102a76940) + 199 at doxygen.cpp:1394
>>   frame #6: 0x0000000100149547 doxygen`buildClassList(rootNav=0x0000000101667060) + 199 at doxygen.cpp:1394
>>   frame #7: 0x0000000100144073 doxygen`parseInput() + 6675 at doxygen.cpp:10981
>>   frame #8: 0x00000001000011c6 doxygen`main(argc=2, argv=0x00007fff5fbff7a8) + 54 at main.cpp:37
>> 
>> 
>> ------------------------------------------------------------------------------
>> Slashdot TV.  Video for Nerds.  Stuff that Matters.
>> http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Doxygen-users mailing list
>> Dox...@li...
>> https://lists.sourceforge.net/lists/listinfo/doxygen-users
> 

[Doxygen-users] file documentation in

[Sebastien L. <slo...@gm...>]

Hi,

I have the following example:

bar/foo.h
   /// \defgroup GRP This is a group

   /// \file bar/foo.h
   /// \ingroup GRP
   /// \brief This file is documented

Then the group page is showing me the file foo.h where as I would have
expected to see bar/foo.h (which is what I can see if I click on the
link generated)

Is it expected or is it a bug?

Tested with 2eece646

Thanks,

Sebastien.

Re: [Doxygen-users] FILE_PATTERNS issue with doxygen 1.8.8

[Ronan <ro...@gm...>]

Thanks guys!

Documentation generation is working again.

Ronan

2014-09-19 21:45 GMT+02:00 Doxygen <do...@gm...>:

> Yes, Albert's analysis and suggested solution are correct.
>
> - Dimitri
>
> On 19 sep. 2014, at 20:09, Albert <alb...@gm...> wrote:
>
>
> As far as I can see in version 1.8.8 a default Parser has been introduced
> for unknown extensions which does not do anything with the file. In the
> past, as far as I can seee, these files were treated as one of the existing
> file types (I think C). Trough EXTENSION_MAPPING you can set the required
> language (in your case probably dtx=C)
>
> Albert
>
> On Fri, Sep 19, 2014 at 11:25 AM, Ronan <ro...@gm...> wrote:
>
>> Hello,
>>
>> For historical reasons, I use "dxt" (d for Doxygen ;-)  extension instead
>> "txt" to write documentation using doxygen syntax and generate html.
>>
>> Doxyfile:
>>
>> FILE_PATTERNS = *.dxt
>>
>> Doxygen:
>>
>> Preprocessing MyFile.dxt...
>> Parsing MyFile.dxt...
>>
>> Result:
>>
>> MyFile.html
>>
>>
>> From version 1.4.5 until 1.8.7, I had no problems
>>
>> But, with doxygen 1.8.8, "Preprocessing/Parsing" is replaced by
>> "Reading", and no more html file is generated:
>>
>> Doxyfile configuration :
>>
>> FILE_PATTERNS = *.dxt
>>
>> Doxygen :
>>
>> Reading MyFile.dxt...
>>
>> Result :
>>
>> None
>>
>>
>> Does someone met the same problem?
>>
>>
>> Regards,
>>
>> Ronan
>>
>>
>> ------------------------------------------------------------------------------
>> Slashdot TV.  Video for Nerds.  Stuff that Matters.
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Doxygen-users mailing list
>> Dox...@li...
>> https://lists.sourceforge.net/lists/listinfo/doxygen-users
>>
>>
>
> ------------------------------------------------------------------------------
> Slashdot TV.  Video for Nerds.  Stuff that Matters.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
>
> _______________________________________________
> Doxygen-users mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-users
>
>

[Doxygen-users] External Functions not Showing on Class Index Page

[Kevin N. <kne...@si...>]

I am having problems showing external functions using the built-in tags 
system.  I run the base.config and have it output the base.tag file with 
the correct information regarding the functions I want to see on the 
"class index" page.  When I run the second iteration with the top.config 
file, with the relevant information below, the functions from base.tag 
don't show up on the "class index" page. There are no errors showing up 
in the doxygen log file.

top.config...

    TAGFILES               = html/base.tag=./base
    ALLEXTERNALS           = YES
    EXTERNAL_GROUPS        = YES
    EXTERNAL_PAGES         = YES


Can someone point out the errors of my ways?

Thanks,
Kevin

Re: [Doxygen-users] Tag file missing public class members

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

Hi David,

Thanks for the reminder.
I'm working on a different way to generate the tag files, i.e. using a separate function rather than to generate it as the side-effect of writing the documentation. That way the workaround with the 'tagDataWritten' flag is no longer needed.

Regards,
  Dimitri

On 20 Sep 2014, at 3:43 , David Thompson <dav...@ki...> wrote:

> Hi all,
> 
> I just wanted to make sure that Jeffrey Melville's patch doesn't get dropped; I was having the same issue (no tag entry for a base class member when a subclass also documented it) and his patch got the tag file working for me.
> 
> 	Thanks,
> 	David
> 
>> Below is a patch that fixed the problem on my codebase. I'm not sure if 
>> it breaks other cases where you actually want to suppress the tag data 
>> being generated multiple times. I can submit a Github pull request if 
>> you'd prefer.
>> 
>> Cheers,
>> Jeff
>> 
>> From b874223b33d4939c53b42df75ce62bcc4acea318 Mon Sep 17 00:00:00 2001
>> From: Jeffrey Melville <jmelville@...>
>> Date: Mon, 8 Sep 2014 13:16:29 -0400
>> Subject: [PATCH] Fix for missing inherited class members in tag files.
>> 
>> Signed-off-by: Jeffrey Melville <jmelville@...>
>> ---
>>  src/memberdef.cpp | 6 +++++-
>>  1 file changed, 5 insertions(+), 1 deletion(-)
>> 
>> diff --git a/src/memberdef.cpp b/src/memberdef.cpp
>> index a25528a..8626e5e 100644
>> --- a/src/memberdef.cpp
>> +++ b/src/memberdef.cpp
>> @@ -3550,7 +3550,11 @@ Specifier MemberDef::virtualness(int count) const
>>  void MemberDef::_writeTagData(const DefType compoundType)
>>  {
>>    unsigned typeMask = 1 << compoundType;
>> -  if ((m_impl->tagDataWritten) & typeMask) return; // member already written for this type
>> +
>> +  // Return if member already written for this compoundType, except if
>> +  // compoundType is a class. This function can be run multiple times for
>> +  // classes in an inheritance hierarchy.
>> +  if (compoundType != TypeClass && (m_impl->tagDataWritten) & typeMask) return;
>>    if (m_impl->mtype==MemberType_EnumValue && m_impl->enumScope &&
>>        m_impl->enumScope->isStrong()) return; // enum value is part of enum
>>    static bool generateTagFile = !Config_getString("GENERATE_TAGFILE").isEmpty();
>> --
>> 1.9.1
> 
> ------------------------------------------------------------------------------
> Slashdot TV.  Video for Nerds.  Stuff that Matters.
> http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
> _______________________________________________
> Doxygen-users mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-users

Re: [Doxygen-users] I can not get tables to work.

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

Hi Doug,

Make sure MARKDOWN_SUPPORT is enabled in the config file and use valid markdown syntax, e.g.:

 /**
  * A class for fails
  * | This Rule Name | Element or Terminal |
  * | -------------: | :------------------ |
  * | left-text =    |                     |
  * |                |         right-text1 |
  * |                |         right-text2 |
  * |                |         right-text3 |
  * |                |         right-text4 |
  * |                |         right-text5 |
  *
  */
 class fails
 {
 };

Note that the @class command is redundant and that the number of |'s is important and should be the same for each line.

Regards,
  Dimitri

On 21 Sep 2014, at 17:03 , Doug Royer <dou...@gm...> wrote:

> 
> In HTML, the tables produces inline text:
> 
>     A class for fails This Rule Name | Element or Terminal | ---—: | :—: | :--— | | left-text | = | | | | right-text1 | | |
>     right-text2 | | | right-text3 | | | right-text4 | | right-text5 |
> 
> Using doxygen 1.8.6
> 
> Did a 'doxygen -g' and used a fresh Doxyfile.
> 
> The source:
> 
>   /**
>         * @class fails
>         * A class for fails
>         * This Rule Name | Element or Terminal
>         * | ------: | :---: | :----- |
>         * | left-text | = | |
>         * | | right-text1 |
>         * | | right-text2 |
>         * | | right-text3 |
>         * | | right-text4
>         * | | right-text5 |
>         *
>         */
>        class fails
>        {
> 
>        public:
>                /**
>                 * fails - constructor
>                 */
>                fails();
> 
>                /**
>                 * fails - destructor
>                 */
>                virtual ~fails();
>        };
> 
> -- 
> 
> Doug Royer - (http://DougRoyer.US)
> Dou...@gm...
> 714-989-6135
> 
> 
> ------------------------------------------------------------------------------
> Slashdot TV.  Video for Nerds.  Stuff that Matters.
> http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk_______________________________________________
> Doxygen-users mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-users

[Doxygen-users] I can not get tables to work.

[Doug R. <dou...@gm...>]

In HTML, the tables produces inline text:

      A class for fails This Rule Name | Element or Terminal | ---—: | 
:—: | :--— | | left-text | = | | | | right-text1 | | |
      right-text2 | | | right-text3 | | | right-text4 | | right-text5 |

Using doxygen 1.8.6

Did a 'doxygen -g' and used a fresh Doxyfile.

The source:

    /**
          * @class fails
          * A class for fails
          * This Rule Name | Element or Terminal
          * | ------: | :---: | :----- |
          * | left-text | = | |
          * | | right-text1 |
          * | | right-text2 |
          * | | right-text3 |
          * | | right-text4
          * | | right-text5 |
          *
          */
         class fails
         {

         public:
                 /**
                  * fails - constructor
                  */
                 fails();

                 /**
                  * fails - destructor
                  */
                 virtual ~fails();
         };

-- 

Doug Royer - (http://DougRoyer.US)
Dou...@gm...
714-989-6135

[Doxygen-users] system calls equivalence

[wave <pro...@gm...>]

i'm trying to port some packages wich calls X11, to a hobbyst os wich 
uses Appserver.

By using Doxygen i could get the calls of appserver and that packs, 
separately.

Now, can Doxygen be used for generating something like a table where one 
side would have the
involved X11 calls and in the other, the Appserver equivalent ones? I'm 
just a student, and
i need to generate this as a guide for being able to edit that code and 
get it working on
without X11 as in my system it's not available and i don't want to use 
it. If Doxygen
is not able to do this, then does exist any other tool for doing such a 
thing?

Thanks.

Re: [Doxygen-users] Crash building class list

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

Hi David,

I would expect that this commit already addresses the problem below:
https://github.com/doxygen/doxygen/commit/6d4044ad43ae1424a256eb1c26992301e7c64f4a

Regards,
  Dimitri

On 20 Sep 2014, at 3:58 , David Thompson <dav...@ki...> wrote:

> Hi all,
> 
> I have succeeded in crashing doxygen 1.8.8; it happens when I use a tag file for the Google sparsehash package in documentation for my own software. When I remove the sparsehash entry from the TAGFILES list, then the documentation builds properly. I've traced the crash to the "Building class list..." phase, where Definition::localName() is called with a NULL Definition*. The full stacktrace is below.
> 
> The problem appears to be in buildScopeFromQualifiedName() at line 1041 of doxygen.cpp, where a NULL innerScope variable is passed to
> 
> 	prevScope->addInnerCompound(innerScope);
> 
> The name parameter and fullScope variable are both "google::has_trivial_constructor< std::pair< T, U > >", i = 1, nsName = "has_trivial_constructor< std::pair< T, U > >", nd = 0, and cd = 0.
> 
> I am happy to try out patches and run things through the debugger, but don't have time to read more of the code. Does anyone have ideas for a fix?
> 
> 	Thanks,
> 	David
> 
> Stack trace:
> 
> * thread #1: tid = 0x2464d42, 0x00000001000ac593 doxygen`Definition::localName(this=0x0000000000000000) const + 19 at definition.cpp:1386, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x8)
>  * frame #0: 0x00000001000ac593 doxygen`Definition::localName(this=0x0000000000000000) const + 19 at definition.cpp:1386
>    frame #1: 0x0000000100380863 doxygen`NamespaceDef::addInnerCompound(this=0x0000000103e07500, d=0x0000000000000000) + 51 at namespacedef.cpp:136
>    frame #2: 0x0000000100165fd1 doxygen`buildScopeFromQualifiedName(name=<unavailable>, level=2, lang=SrcLangExt_Unknown, tagInfo=0x00000001016d6e20) + 1537 at doxygen.cpp:1041
>    frame #3: 0x00000001001822c4 doxygen`addClassToContext(rootNav=0x0000000102a4a0f0) + 2052 at doxygen.cpp:1315
>    frame #4: 0x00000001001494db doxygen`buildClassList(rootNav=0x0000000102a4a0f0) + 91 at doxygen.cpp:1392
>    frame #5: 0x0000000100149547 doxygen`buildClassList(rootNav=0x0000000102a76940) + 199 at doxygen.cpp:1394
>    frame #6: 0x0000000100149547 doxygen`buildClassList(rootNav=0x0000000101667060) + 199 at doxygen.cpp:1394
>    frame #7: 0x0000000100144073 doxygen`parseInput() + 6675 at doxygen.cpp:10981
>    frame #8: 0x00000001000011c6 doxygen`main(argc=2, argv=0x00007fff5fbff7a8) + 54 at main.cpp:37
> 
> 
> ------------------------------------------------------------------------------
> Slashdot TV.  Video for Nerds.  Stuff that Matters.
> http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
> _______________________________________________
> Doxygen-users mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-users

[Doxygen-users] Crash building class list

[David T. <dav...@ki...>]

Hi all,

I have succeeded in crashing doxygen 1.8.8; it happens when I use a tag file for the Google sparsehash package in documentation for my own software. When I remove the sparsehash entry from the TAGFILES list, then the documentation builds properly. I've traced the crash to the "Building class list..." phase, where Definition::localName() is called with a NULL Definition*. The full stacktrace is below.

The problem appears to be in buildScopeFromQualifiedName() at line 1041 of doxygen.cpp, where a NULL innerScope variable is passed to

	prevScope->addInnerCompound(innerScope);

The name parameter and fullScope variable are both "google::has_trivial_constructor< std::pair< T, U > >", i = 1, nsName = "has_trivial_constructor< std::pair< T, U > >", nd = 0, and cd = 0.

I am happy to try out patches and run things through the debugger, but don't have time to read more of the code. Does anyone have ideas for a fix?

	Thanks,
	David

Stack trace:

* thread #1: tid = 0x2464d42, 0x00000001000ac593 doxygen`Definition::localName(this=0x0000000000000000) const + 19 at definition.cpp:1386, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS (code=1, address=0x8)
  * frame #0: 0x00000001000ac593 doxygen`Definition::localName(this=0x0000000000000000) const + 19 at definition.cpp:1386
    frame #1: 0x0000000100380863 doxygen`NamespaceDef::addInnerCompound(this=0x0000000103e07500, d=0x0000000000000000) + 51 at namespacedef.cpp:136
    frame #2: 0x0000000100165fd1 doxygen`buildScopeFromQualifiedName(name=<unavailable>, level=2, lang=SrcLangExt_Unknown, tagInfo=0x00000001016d6e20) + 1537 at doxygen.cpp:1041
    frame #3: 0x00000001001822c4 doxygen`addClassToContext(rootNav=0x0000000102a4a0f0) + 2052 at doxygen.cpp:1315
    frame #4: 0x00000001001494db doxygen`buildClassList(rootNav=0x0000000102a4a0f0) + 91 at doxygen.cpp:1392
    frame #5: 0x0000000100149547 doxygen`buildClassList(rootNav=0x0000000102a76940) + 199 at doxygen.cpp:1394
    frame #6: 0x0000000100149547 doxygen`buildClassList(rootNav=0x0000000101667060) + 199 at doxygen.cpp:1394
    frame #7: 0x0000000100144073 doxygen`parseInput() + 6675 at doxygen.cpp:10981
    frame #8: 0x00000001000011c6 doxygen`main(argc=2, argv=0x00007fff5fbff7a8) + 54 at main.cpp:37

Re: [Doxygen-users] Tag file missing public class members

[David T. <dav...@ki...>]

Hi all,

I just wanted to make sure that Jeffrey Melville's patch doesn't get dropped; I was having the same issue (no tag entry for a base class member when a subclass also documented it) and his patch got the tag file working for me.

	Thanks,
	David

> Below is a patch that fixed the problem on my codebase. I'm not sure if 
> it breaks other cases where you actually want to suppress the tag data 
> being generated multiple times. I can submit a Github pull request if 
> you'd prefer.
> 
> Cheers,
> Jeff
> 
> From b874223b33d4939c53b42df75ce62bcc4acea318 Mon Sep 17 00:00:00 2001
> From: Jeffrey Melville <jmelville@...>
> Date: Mon, 8 Sep 2014 13:16:29 -0400
> Subject: [PATCH] Fix for missing inherited class members in tag files.
> 
> Signed-off-by: Jeffrey Melville <jmelville@...>
> ---
>   src/memberdef.cpp | 6 +++++-
>   1 file changed, 5 insertions(+), 1 deletion(-)
> 
> diff --git a/src/memberdef.cpp b/src/memberdef.cpp
> index a25528a..8626e5e 100644
> --- a/src/memberdef.cpp
> +++ b/src/memberdef.cpp
> @@ -3550,7 +3550,11 @@ Specifier MemberDef::virtualness(int count) const
>   void MemberDef::_writeTagData(const DefType compoundType)
>   {
>     unsigned typeMask = 1 << compoundType;
> -  if ((m_impl->tagDataWritten) & typeMask) return; // member already written for this type
> +
> +  // Return if member already written for this compoundType, except if
> +  // compoundType is a class. This function can be run multiple times for
> +  // classes in an inheritance hierarchy.
> +  if (compoundType != TypeClass && (m_impl->tagDataWritten) & typeMask) return;
>     if (m_impl->mtype==MemberType_EnumValue && m_impl->enumScope &&
>         m_impl->enumScope->isStrong()) return; // enum value is part of enum
>     static bool generateTagFile = !Config_getString("GENERATE_TAGFILE").isEmpty();
> --
> 1.9.1

Re: [Doxygen-users] FILE_PATTERNS issue with doxygen 1.8.8

[Doxygen <do...@gm...>]

Yes, Albert's analysis and suggested solution are correct.

- Dimitri

> On 19 sep. 2014, at 20:09, Albert <alb...@gm...> wrote:
> 
> 
> As far as I can see in version 1.8.8 a default Parser has been introduced for unknown extensions which does not do anything with the file. In the past, as far as I can seee, these files were treated as one of the existing file types (I think C). Trough EXTENSION_MAPPING you can set the required language (in your case probably dtx=C)
> 
> Albert
> 
>> On Fri, Sep 19, 2014 at 11:25 AM, Ronan <ro...@gm...> wrote:
>> Hello,
>> 
>> For historical reasons, I use "dxt" (d for Doxygen ;-)  extension instead "txt" to write documentation using doxygen syntax and generate html.
>> 
>> Doxyfile:
>> 
>> FILE_PATTERNS = *.dxt
>> 
>> Doxygen:
>> 
>> Preprocessing MyFile.dxt...
>> Parsing MyFile.dxt...
>> 
>> Result:
>> 
>> MyFile.html
>> 
>> 
>> From version 1.4.5 until 1.8.7, I had no problems
>> 
>> But, with doxygen 1.8.8, "Preprocessing/Parsing" is replaced by "Reading", and no more html file is generated:
>> 
>> Doxyfile configuration :
>> 
>> FILE_PATTERNS = *.dxt
>> 
>> Doxygen :
>> 
>> Reading MyFile.dxt...
>> 
>> Result :
>> 
>> None
>> 
>> 
>> Does someone met the same problem?
>> 
>> 
>> Regards,
>> 
>> Ronan
>> 
>> ------------------------------------------------------------------------------
>> Slashdot TV.  Video for Nerds.  Stuff that Matters.
>> http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
>> _______________________________________________
>> Doxygen-users mailing list
>> Dox...@li...
>> https://lists.sourceforge.net/lists/listinfo/doxygen-users
> 
> ------------------------------------------------------------------------------
> Slashdot TV.  Video for Nerds.  Stuff that Matters.
> http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
> _______________________________________________
> Doxygen-users mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-users

Re: [Doxygen-users] FILE_PATTERNS issue with doxygen 1.8.8

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

As far as I can see in version 1.8.8 a default Parser has been introduced
for unknown extensions which does not do anything with the file. In the
past, as far as I can seee, these files were treated as one of the existing
file types (I think C). Trough EXTENSION_MAPPING you can set the required
language (in your case probably dtx=C)

Albert

On Fri, Sep 19, 2014 at 11:25 AM, Ronan <ro...@gm...> wrote:

> Hello,
>
> For historical reasons, I use "dxt" (d for Doxygen ;-)  extension instead
> "txt" to write documentation using doxygen syntax and generate html.
>
> Doxyfile:
>
> FILE_PATTERNS = *.dxt
>
> Doxygen:
>
> Preprocessing MyFile.dxt...
> Parsing MyFile.dxt...
>
> Result:
>
> MyFile.html
>
>
> From version 1.4.5 until 1.8.7, I had no problems
>
> But, with doxygen 1.8.8, "Preprocessing/Parsing" is replaced by "Reading",
> and no more html file is generated:
>
> Doxyfile configuration :
>
> FILE_PATTERNS = *.dxt
>
> Doxygen :
>
> Reading MyFile.dxt...
>
> Result :
>
> None
>
>
> Does someone met the same problem?
>
>
> Regards,
>
> Ronan
>
>
> ------------------------------------------------------------------------------
> Slashdot TV.  Video for Nerds.  Stuff that Matters.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
> _______________________________________________
> Doxygen-users mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-users
>
>

[Doxygen-users] template parsing bug?

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

Hi all.

In one of my headers I am having an overloaded C++ function template with
a rather complex signature that I am trying to document with doxygen. The
documentation is not located inside that header file, but in another file.

This is the code I am talking about:

			template<typename Ftype> typename
Common::Helpers::EnableIf<!Common::Helpers::ConfirmAllowed<Ftype>::dimensi
ons, bool>::type opRaiseEvent(bool reliable, Ftype parameters, nByte
eventCode, nByte channelID=0, nByte
eventCaching=Lite::EventCache::DO_NOT_CACHE, const int*
targetPlayers=NULL, short numTargetPlayers=0, nByte
receiverGroup=Lite::ReceiverGroup::OTHERS, nByte interestGroup=0, bool
forwardToWebhook=false, int cacheSliceIndex=0)
			{
				return opRaiseEvent(reliable,
Common::Helpers::ValueToObject::get(parameters), eventCode, channelID,
eventCaching, targetPlayers, numTargetPlayers, receiverGroup,
interestGroup, forwardToWebhook, cacheSliceIndex);
			}
			template<typename Ftype> typename
Common::Helpers::EnableIf<Common::Helpers::ConfirmAllowed<Ftype>::dimensio
ns==1, bool>::type opRaiseEvent(bool reliable, Ftype pParameterArray,
typename Common::Helpers::ArrayLengthType<Ftype>::type arrSize, nByte
eventCode, nByte channelID=0, nByte
eventCaching=Lite::EventCache::DO_NOT_CACHE, const int*
targetPlayers=NULL, short numTargetPlayers=0, nByte
receiverGroup=Lite::ReceiverGroup::OTHERS, nByte interestGroup=0, bool
forwardToWebhook=false, int cacheSliceIndex=0)
			{
				return opRaiseEvent(reliable,
Common::Helpers::ValueToObject::get(pParameterArray, arrSize), eventCode,
channelID, eventCaching, targetPlayers, numTargetPlayers, receiverGroup,
interestGroup, forwardToWebhook, cacheSliceIndex);
			}
			template<typename Ftype> typename
Common::Helpers::EnableIf<(Common::Helpers::ConfirmAllowed<Ftype>::dimensi
ons>1), bool>::type opRaiseEvent(bool reliable, Ftype pParameterArray,
const short* pArrSizes, nByte eventCode, nByte channelID=0, nByte
eventCaching=Lite::EventCache::DO_NOT_CACHE, const int*
targetPlayers=NULL, short numTargetPlayers=0, nByte
receiverGroup=Lite::ReceiverGroup::OTHERS, nByte interestGroup=0, bool
forwardToWebhook=false, int cacheSliceIndex=0)
			{
				return opRaiseEvent(reliable,
Common::Helpers::ValueToObject::get(pParameterArray, pArrSizes),
eventCode, channelID, eventCaching, targetPlayers, numTargetPlayers,
receiverGroup, interestGroup, forwardToWebhook, cacheSliceIndex);
			}

Doxygen is able to nicely match signature and according documentation
through doygens "@fn"syntax for the first 2 overloads.
However for the third one  I am getting the following error message:

     [exec]
D:/dev/egn/photon-sdk-native/trunk/Photon-cpp/src/LitePeer.cpp:97:
warning: no uniquely matching class member found for
     [exec]   template< typename Ftype > typename)
Common::Helpers::EnableIf<(Common::Helpers::ConfirmAllowed< Ftype
>::dimensions > bool::type opRaiseEvent(Common::Helpers::ConfirmAllowed<
Ftype >::dimensions,1) const =0
     [exec] Possible candidates:
     [exec]   'template < Ftype >
     [exec]   Common::Helpers::EnableIf<!Common::Helpers::ConfirmAllowed<
Ftype >::dimensions, bool >::type LitePeer::opRaiseEvent(bool reliable,
Ftype parameters, nByte eventCode, nByte channelID=0, nByte
eventCaching=Lite::EventCache::DO_NOT_CACHE, const int
*targetPlayers=NULL, short numTargetPlayers=0, nByte
receiverGroup=Lite::ReceiverGroup::OTHERS, nByte interestGroup=0)' at line
29 of file D:/dev/egn/photon-sdk-native/trunk/Photon-cpp/inc/LitePeer.h
     [exec]   'template < Ftype >
     [exec]   Common::Helpers::EnableIf< Common::Helpers::ConfirmAllowed<
Ftype >::dimensions==1, bool >::type LitePeer::opRaiseEvent(bool reliable,
Ftype pParameterArray, typename Common::Helpers::ArrayLengthType< Ftype
>::type arrSize, nByte eventCode, nByte channelID=0, nByte
eventCaching=Lite::EventCache::DO_NOT_CACHE, const int
*targetPlayers=NULL, short numTargetPlayers=0, nByte
receiverGroup=Lite::ReceiverGroup::OTHERS, nByte interestGroup=0)' at line
33 of file D:/dev/egn/photon-sdk-native/trunk/Photon-cpp/inc/LitePeer.h
     [exec]   'template < Ftype >
     [exec]   bool::type LitePeer::opRaiseEvent(bool reliable, Ftype
pParameterArray, const short *pArrSizes, nByte eventCode, nByte
channelID=0, nByte eventCaching=Lite::EventCache::DO_NOT_CACHE, const int
*targetPlayers=NULL, short numTargetPlayers=0, nByte
receiverGroup=Lite::ReceiverGroup::OTHERS, nByte interestGroup=0)' at line
37 of file D:/dev/egn/photon-sdk-native/trunk/Photon-cpp/inc/LitePeer.h
     [exec]   virtual bool LitePeer::opRaiseEvent(bool reliable, const
Common::Object &parameters, nByte eventCode, nByte channelID=0, nByte
eventCaching=Lite::EventCache::DO_NOT_CACHE, const int
*targetPlayers=NULL, short numTargetPlayers=0, nByte
receiverGroup=Lite::ReceiverGroup::OTHERS, nByte interestGroup=0)' at line
52 of file D:/dev/egn/photon-sdk-native/trunk/Photon-cpp/inc/LitePeer.h



I could successfully track the source of the problem down to the
dimensions>1 comparison. Apparently doxygens parser despite the () still
falsely interprets the > operator as a template closing bracket.

Is there any way I in which can force doxygen to correctly interpret the >
operator as what it is?


Kind regards,
Stefan.

-- 
--
Exit Games | www.exitgames.com | @exitgames | +49 40 413 596 0

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

++ Add Chat: http://j.mp/PhotonChat
++ Start Turnbased: http://j.mp/PhotonTurnbased
++ Unity Networking that just works: http://j.mp/PhotonUnity
++ Follow http://twitter.com/exitgames for Photon announcements

[Doxygen-users] FILE_PATTERNS issue with doxygen 1.8.8

[Ronan <ro...@gm...>]

Hello,

For historical reasons, I use "dxt" (d for Doxygen ;-)  extension instead
"txt" to write documentation using doxygen syntax and generate html.

Doxyfile:

FILE_PATTERNS = *.dxt

Doxygen:

Preprocessing MyFile.dxt...
Parsing MyFile.dxt...

Result:

MyFile.html


>From version 1.4.5 until 1.8.7, I had no problems

But, with doxygen 1.8.8, "Preprocessing/Parsing" is replaced by "Reading",
and no more html file is generated:

Doxyfile configuration :

FILE_PATTERNS = *.dxt

Doxygen :

Reading MyFile.dxt...

Result :

None


Does someone met the same problem?


Regards,

Ronan

[Doxygen-users] X11 and Appserver equivalent calls

[wave <pro...@gm...>]

Hello

I'm porting some packages for gnu/linux and other free systems, to a 
hobbyst system where instead of X11 as video,
i have something called Appserver.

I have to edit several files replacing calls from X11 to Appserver ones, 
Doxygen did a great job letting me
get a document wich shows the calls of each one, now, i'd like to 
generate a document where, for example,
i could have on one side of the sheet X11 calls and Appserver equivalent 
calls, where my goal is to
use that document as a call replacing guide. If generating that kind of 
document can be done, how
should i do i use Doxygen for?

[Doxygen-users] Bug in doxysearch.cpp?

[Keith R. <Kei...@ne...>]

Hi,

We use the webserver doxygen search capability using the provided doxysearch.cgi and doxyindexer. We noticed an issue when searching for a particular word (a C++ namespace) and a blank screen appeared in the search results. After debugging it appears that one of the returned search items is a global variable, something like:

const std::string TheNamespace::g_Name("some text");

The search query used was TheNamespace. The search tagged this item as a "function" type. The resultant JSON was:

start omitted ...
"type": "function",
"name": "TheNamespace::g_Name("some text")",
"tag",
... end omitted.

The value of "name" is invalid JSON due to the quotes in the constructor (the console output of Chrome also reported an error - presumably from the getJSON call in the searchFor JavaScript function).

In our local version of doxysearch.cpp I wrapped the call to "doc.get_value(FIELD_ARGS)" in a call to escapeString() which seems to fix the problem.

Hope this helps!

Keith

Re: [Doxygen-users] Tag file missing public class members

[Jeffrey M. <jme...@mi...>]

On 8/28/2014 4:30 PM, Jeffrey Melville wrote:
> Dimitri,
>
> On 8/28/2014 2:03 PM, Dimitri van Heesch wrote:
>> Hi Jeffrey,
>>
>> On 27 Aug 2014, at 17:59 , Jeffrey Melville <jme...@mi...> wrote:
>>
>>> All,
>>>
>>> I'm working on two closely related source trees that generate Doxygen
>>> separately. To cross-link the Doxygen HTML, we just started using
>>> GENERATE_TAGFILE and TAGFILES for ProjectA and Project B respectively.
>>>
>>> I noticed that some functions are missing from the tag file in 1.8.6,
>>> 1.8.8, and the current git head. The tag file is complete when I
>>> generate it with 1.8.2. The was a similar thread
>>> (http://doxygen.10944.n7.nabble.com/Tag-files-and-linking-to-variables-td5788.html)
>>> that referenced this bug:
>>> (https://bugzilla.gnome.org/show_bug.cgi?id=694376). The bug was
>>> supposed to be fixed in 1.8.4 but I am still seeing my issue.
>>>
>>> It seems to involve hierarchies similar to the one below. In the actual
>>> codebase, all members are documented but I ommitted the documentation
>>> here for brevity.
>>>
>>> The tag file only includes private members of class A (i.e. foo is not
>>> listed). In one case,
>>> the tag file for a B-style class even includes the function ~A().
>>>
>>> This is problematic because the ProjectB documentation for class C does
>>> not properly link to the overridden function in ProjectA.
>>>
>>> If I generate the tag file for ProjectA using Doxygen 1.8.2, then build
>>> the Doxygen for ProjectB with Doxygen 1.8.6 using that tag file,
>>> everything is fine. We have some compatibility issues with the rest of
>>> the Doxyfile with 1.8.2.
>>>
>>> Unfortunately, I haven't been able to replicate the problem with a
>>> simple test case like this one. It only occurs with the full codebase,
>>> which I am unable to provide.
>>>
>>> Is this enough for anyone to have an idea? I'm not opposed to hacking on
>>> the Doxygen source code to find a patch but I could use a tip on where
>>> to start looking.
>>
>> I'm afraid it is not enough to directly pinpoint the problem.
>> Some questions:
>> - does the issue occur with just one tag file, and one project using it, or is there
>>     a chain of tag files, where also projectA imports tag files?
>
> No, ProjectA does not import any tag files. It does declare
> BUILTIN_STL_SUPPORT. ProjectB is the only consumer of ProjectA's tag
> file. It only imports the single tag file.
>
>> - is a symbol with the same name as the one that is not correctly appearing
>>     in projectA's tag file (i.e. foo), also in some other tag file?
>
> No, since project A does not import any other tag flies.
> I don't know if this matters, but another source file forward declares
> one of the affected classes.
>
>>
>> If you want to see places in the code where information is written to the tag file,
>> look for "Doxygen::tagFile" in the source code. For member information look in
>> src/memberdef.cpp
>
> Ok. I'll poke around. Have there been any significant changes since
> 1.8.2 in the way tag files are generated?
>
>>
>> Regards,
>>     Dimitri
>>
>
> Thanks,
> Jeff
>
> P.S. Sorry for the double send, I forgot to include the list.
>
>>>
>>> Cheers,
>>> Jeff
>>>
>>>
>>> // Class A and B are in ProjectA
>>> class A
>>> {
>>> public:
>>>      virtual ~A() {}
>>>      virtual void foo() {}
>>> protected:
>>>      A() {}
>>> private:
>>>      int a_private;
>>> };
>>>
>>> class B : public A
>>> {
>>> public:
>>>       virtual ~B() {}
>>>       virtual void bar() = 0;
>>> protected:
>>>       B() {}
>>> private:
>>>       int b_private;
>>> };
>>>
>>> // Class C is in ProjectB
>>> class C : public B
>>> {
>>> public:
>>>       void foo() { /* Do something */ }
>>>       void bar() { /* Do something */ }
>>> };
>>>
>>> ------------------------------------------------------------------------------
>>> Slashdot TV.
>>> Video for Nerds.  Stuff that matters.
>>> http://tv.slashdot.org/
>>> _______________________________________________
>>> Doxygen-users mailing list
>>> Dox...@li...
>>> https://lists.sourceforge.net/lists/listinfo/doxygen-users
>>
>
>
> ------------------------------------------------------------------------------
> Slashdot TV.
> Video for Nerds.  Stuff that matters.
> http://tv.slashdot.org/
> _______________________________________________
> Doxygen-users mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-users
>

Thanks for the tip, I made some progress on tracking down this issue. It 
is very closely related to: 
https://bugzilla.gnome.org/show_bug.cgi?id=694376.

The problem is that each member can have _writeTagData called more than 
once. The fix for the previous bug addressed cases where _writeTagData 
is called for different "compound types." It's still possible for 
_writeTagData to be called multiple types for each class in an 
inheritance hierarchy when functions are inherited but not overridden. 
Things get really weird when the derived class gets processed before the 
base class (as is the case in my codebase). The call to 
writeInheritedMemberDeclarations marks the tagDataWritten flag for 
functions inherited from the base class, preventing them from being 
emitted when the base class is processed.

Below is a patch that fixed the problem on my codebase. I'm not sure if 
it breaks other cases where you actually want to suppress the tag data 
being generated multiple times. I can submit a Github pull request if 
you'd prefer.

Cheers,
Jeff

 From b874223b33d4939c53b42df75ce62bcc4acea318 Mon Sep 17 00:00:00 2001
From: Jeffrey Melville <jme...@mi...>
Date: Mon, 8 Sep 2014 13:16:29 -0400
Subject: [PATCH] Fix for missing inherited class members in tag files.

Signed-off-by: Jeffrey Melville <jme...@mi...>
---
  src/memberdef.cpp | 6 +++++-
  1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/src/memberdef.cpp b/src/memberdef.cpp
index a25528a..8626e5e 100644
--- a/src/memberdef.cpp
+++ b/src/memberdef.cpp
@@ -3550,7 +3550,11 @@ Specifier MemberDef::virtualness(int count) const
  void MemberDef::_writeTagData(const DefType compoundType)
  {
    unsigned typeMask = 1 << compoundType;
-  if ((m_impl->tagDataWritten) & typeMask) return; // member already 
written for this type
+
+  // Return if member already written for this compoundType, except if
+  // compoundType is a class. This function can be run multiple times for
+  // classes in an inheritance hierarchy.
+  if (compoundType != TypeClass && (m_impl->tagDataWritten) & typeMask) 
return;
    if (m_impl->mtype==MemberType_EnumValue && m_impl->enumScope &&
        m_impl->enumScope->isStrong()) return; // enum value is part of enum
    static bool generateTagFile = 
!Config_getString("GENERATE_TAGFILE").isEmpty();
--
1.9.1

[Doxygen-users] Doxygen dot. Draw link between classes by annotation

[Dmitry R. <di...@gm...>]

Hi,
Doxygen can generate class diagrams with graphiz.

For example:

|class  A{...};
class  Bextends  A{...};|

 From this code I can generate a picture where doxygen can show that one 
class it the parent of an other.

But is there a way to generate a picture from code with manual 
references between classes?

For example when I describe DB scheme and use contract classes 
(http://developer.android.com/training/basics/data-storage/databases.html#DefineContract) 
I want to perform smth like this:

|class  MainClass  {
     class  A{
         String  COLUMN_ID=  "id_a";
     }

     /**
      * {@dotlinkto MainClass.A}
     **/
     @OrAnotationToDrawLink(A.class)
     class  B{
         String  COLUMN_ID=  "id_b";
         String  COLUMN_FOREIGN_KEY_TO_A=  "id_a_key";
     }
}|

And generate a picture of 2 classes A and B with reference between them.

I've tried to search through documentation but can't find any suitable 
examples or explanation about custom drawing in javadoc+doxygen+graphviz.


http://stackoverflow.com/questions/25610378/doxygen-dot-draw-link-between-classes-by-annotation

-- 
Best regards,
Dmitry.

[Doxygen-users] Is it possible to mimic overloading in PHP?

[Willem B. <w-...@dd...>]

I mean, it is possible to do that in PHP, but I want to reflect this in
the documentation. For example, I have written a DateTime class and it
can be constructed without a parameter to get "now", with an integer
(meaning unix timestamp), three integers denoting year, month and day,
and so on.

I would like the documentation to treat them as if they were different
constructors, instead of one without parameters (it calls
func_get_args() to read its parameters) that handles all the possibilities.

I tried:

/// @fn clsDateTime::__construct()
/// Construct a clsDateTime object representing now.

/// @fn clsDateTime::__construct($mixTimeStamp)
/// Construct a clsDateTime object representing the given timestamp.
/// If the timestamp is numeric, it is treated as a unix timestamp, with
decimal seconds if it is a float.\n
/// If it is a string, it is parsed as a delimited set of the values for
year, month, day, hour, minute and second,
/// unless the string is one of the special values "now", "today", or
"tomorrow".\n
/// If it is a clsDateTime object, the new object is a copy.

/// @fn clsDateTime::__construct($intYear, $intMonth, $intDay)
/// @param integer $intYear The year as a number
/// @param integer $intMonth The month as a number
/// @param integer $intDay The day of the month as a number.
/// Construct a clsDateTime object representing the given date.

But all this does is to combine all the above sections into one. It is
possible to have Doxygen create overloaded documentation for a language
that does not really support overloading, just for clarity?

Best regards,

Willem Bogaerts