doxygen-users — List for users of doxygen

[Doxygen-users] RE: problem with class hierarchies with templates

[Kris T. <kri...@ic...>]

Hi,

further on this problem. I've enabled the dot graphs now. And I am surprised
with the result. First the hierarchy again:

> The simplest
> example of my problem is the following hierarchy
> //! V
> class V {};
> //! K
> template <class T> class K : public T {};
> //! KV
> class KV : public K<V> {};
>

what is the result?

DOT ENABLED
-----------
- In the Class Hierarchy (hierarchy.html), it is not recognised that the
hierarchy
is KV : K<V>: V. (It just mentions KV: K). This is also true for the
graphical hierarchy.

- in the Inheritance diagram of K, I get confusingly
	KV : K : T
  (I'd prefer KV : K<T> : T and some indication that T is a template
parameter)

- in the Inheritance diagram of KV, I get CORRECTLY
	KV : K<V> : V


DOT DISABLED
-----------
- The Class Hierarchy (hierarchy.html) is the same.

- in the Inheritance diagram of K, I get now
	KV : K

- in the Inheritance diagram of KV, I get now
	KV : K<V>


It's strange that the inheritances are different when dot is dis/enabled. I
hope that it's easy to fix this, as at least one diagram was correct...


Attached is my doxygen input file I used.


All the best,


Kris Thielemans

PS: I'm on the mailing list again

[Doxygen-users] problem with class hierarchies with templates

[Kris T. <kri...@cs...>]

Hi,

this is essentially a repost of a half-year old question, prompted by the
following in the Changelog of version 1.2.8.1
---------------------
The dot generated inheritance and collaboration graphs for classes should
now show the proper template instantation for the derived/used classes. For
instance it should show that class S uses class V (indirectly) in the
following example:
           class V {};
           template<class T> class U1 { T *m_t; };
           template<class T> class U2 { U1<T> *m_t; };
           template<class T> class B1 { U2<T> *m_t; };
           template<class T> class B2 : public B1<T> {};
           class S : public B2<V> {};
---------------------
So, I went and tried this new version on my code.  However, the Class
Hierarchy (as documented in hierarchy.html) is still wrong. The simplest
example of my problem is the following hierarchy
//! V
class V {};
//! K
template <class T> class K : public T {};
//! KV
class KV : public K<V> {};

In the Class Hierarchy, it is not recognised that the hierarchy is KV : K<V>
: V. (It just mentions KV: K)

Dimitri mentioned at the time that handling the above example wouldn't be
too difficult, but he wasn't sure about the most general case. I'm sort of
thinking that a fix for the simple cases would make already a lot of people
happy... Any developments? (This problem really screws up the documentation
of our project).

Just doing what the Changelog tells me:
---------------------
Please report any example of class hierarchies that are not shown properly.
---------------------

All the best,


Kris Thielemans

PS: please reply to me personally as well, as I'm not on the mailing list
anymore.

Re: [Doxygen-users] Aliases and \test

[Christian H. <ch...@os...>]

Hi, it's me again ...

another nice behaviour is that the file reference looks like that:

	Module Name

	<p>\test 1

	...

I think it should be a test list reference?

Christian.

[Doxygen-users] Aliases and \test

[Christian H. <ch...@os...>]

Hi,

I substituted in my source code all

	\test jack: foo
	\test john: bar

by some aliases:

ALIASES = "jack=\test jack:" "john=\test john:"

	\jack foo
	\john bar

But it doesn't work. Doxygen does not recognize the "\john bar" as "\test ..."
sequence and merges the statements to:

	"... jack: foo \test john: bar ..."

If I use \note instead of \test it works.
Where is my fault or is it a bug?

I use \test get a seperated list of programmer's comments. Is there another
way to do this?

Ciao,
Christian.

Re: Re: [Doxygen-users] Function grouping problem

[Arkadiusz P. <wo...@so...>]

On Thu, Jun 07, 2001 at 08:58:43AM +0200, Patrick Ohly wrote:
> On Wed, Jun 06, 2001 at 11:44:10AM -0700, Marc Betz wrote:
> > a group name (the @name command), like so:
> > /*! \defgroup Groupname Collection Classes
> >  *  This set of classes supports various sorts of collections.
> >  */
> > class SomeClass {
> > ...
> > //@{
> > someFunc1();
> >   //!< Documentation for this group of functions.
> > someFunc2();
> > someFunc3();
> > //@}
> > ...
> > }
> > I find that the function group appears on and is documented on some
> > module page (it is hard to predict which one), not on the class
> > description page.
> Which version of doxygen are you using? Some versions had this kind
> of problem, but grouping was partly rewritten since then and the latest
> version should work as expected.

I've noticed the same problem. But I'm sure that defining empty group is a
kind of religion, not the solve of the problem. Yes, I've tried it too, but
it stopped to work now for me... ;-). I haven't time to extract strict
simple example of code, but what I see: if you define some groups then not
every unnamed group is collected on module page. I think it can be every
group which is parsed _after_ any ,,\ingroup'' command (named too). I've
tried adding ,,\class'' command at ,,\ingroupped'' class comment, but it
works sometimes only (yes, it's voo-doo, I know, but it worked). I'm using
doxygen 1.2.7 version now (1.2.1 doesn't do this) - but didn't see anything
in v. 1.2.8 changelog about it.

I have another problem yet: tags doesn't work for me. Core suggests segfault
on an ,,empty'' object (sorry, I have no code now) with pointer 0x300000
(too even for me as a pointer). Gcc version incompatibility? I know that
it's buggy. But, again, 1.2.1 works... ;-) I debugged it for a while: object
_is_ initialized, but later variable changes... A kind of buffer overflow, I
think rather. Dimitri, I can ,,generate'' core if you need...

I've tested on two Linuxes: Slackware 7.1 and RedHat 6.0 - both the same
egcs (2.95-2 as I remember).

RE: [Doxygen-users] DOT Tool for windows

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

Hi Doxygeners,

here is a message that I have obtained from the Graphviz (dot)
people.  I have to confirm Dimitri's observation that they really
pay attention to the bug reports, and they try to solve the things
quickly.  There still is an (e-mail) discussion between them how
to solve the details around the problem.

John Ellson wrote...
>
> The first problem was that the default: 'graph [margin="0.5,0.5"]' was
> not being properly supported in the bitmap output formats.
> A fix for this problem is now in CVS.
> 
> The problem with the slightly rotated line is I'm sure a rounding problem.
> The box shape is drawn by the generic polygon shape code, and rotated
> 90deg because of the rank=LR.  I suspect that the rotation is causing the
> problem.    I don't plan to do anything more about this on the grounds
> it should be less noticeable now that the margins are fixed.
> 
> Please note that the default margin size of 0.5 inches is probably more
> than you want for a diagram embedded in a web page.  You can override
> the default by adding something like:
> 	graph [margin="0.2,0.1"]
> to the top of your .dot files.

Petr

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

Re: (off-topic) RE: [Doxygen-users] Documenting IDL

[Hendrik S. <Do...@HS...>]

"Victor A. Wagner, Jr." <va...@ru...> wrote:

> or use void* like I ORIGINALLY suggested (and is suggested by looking at 
> how the STL does it with iterators.

  It's easy to confuse this with a pointer to the object 
  taken care of by the smart pointer. 

> [...] 
> >The "the mythical 'logical' type that 'if', 'while' etc use" is not 'bool' - I
> >suppose you could produce a parser that used bool there, but just taking a 
> >straw
> >poll around the office, the guy sitting next to me (working on a C compiler)
> >uses 'long int' for 'if' etc, which is what the Standard says you do 
> >(hence the
> >use of operator int() to feed 'if' in the oldest code). Meanwhile, in my
> [...]

  I'm not so sure about that. But I always thought, since 
  the standard it's 'bool' for C++. (The guy next to you 
  is working on a C compiler, after all. ;^> )

> > >   template<class T>
> > >   class SmartPtr {
> > >     private:
> > >       class Tester {
> > >         void operator delete(void*);
> > >       };
> > >     public:
> > >       operator Tester*() const
> > >       {
> > >         if( !IsValid() )
> > >           return NULL;
> > >         static Tester tester;
> > >         return tester;
> > >       }
> > >       // ...
> > >   };
> [...]
> >Aha, yet another approach :-)
> >
> >The suggestions - _all_ of them - all have their merits and all can all work
> >extremely well, but, just like the search the One True String Class, there 
> >is no
> >absolute best answer to this. Shame really.
> [...]

  So what's the drawback of this one? 

  Schobi

Re: [Doxygen-users] EXPAND_AS_DEFINED and Poor Mans Inheritance

[Hendrik S. <Do...@HS...>]

"Peter Steiner" <pet...@hu...> wrote:

> On Sun, 10 Jun 2001 23:02:34 +0200, Hendrik Schober wrote:
> 
> > "Peter Steiner" <pet...@hu...> wrote:
> 
> >> [...]
> >> It seems that the doxygen comments inside my macro BASECLASS are
> >> swallowed during the preprocessing stage. 
> 
> >   AFAIK that's what the C++ standard says how it should be. 
> 
> Where does it state this? A very quick glance at section 2.7 (Comments)
> and chapter 16 (Preprocessing Directives) didn't give any statement
> _when_ to remove comments. 

  Sorry, no chapter and verse available from me. 
  My English is way to bad to read the C++ standard 
  (except when I have a hard time to fall asleep).
  It's what I seem to remember from discussions on 
  comp.lang-c++.moderated. 

>                            To be exactly, I'm more interested in the C
> standard in this case anyway, as the source is C (or I'd be able to use
> C++ inheritance instead of some obscure macro technology...)

  Oh, C. No idea. 

> And as doxygen does not see the fully preprocessed source
> (or it wouldn't see _any_ comment), it doesn't really matter what the
> C++ or C standard says...

  What I meant was, that doxygen seems to be C++ 
  standard compliant in respect to comments within 
  preprocessor macros. 

> [...] But doxygen doesn't use the compilers preprocessor, it uses
> its own. I just plea for this _feature_ inside doxygen...

  Ah, I see. I guess it was too late last night... 

> Regards
> 
> Peter

  Schobi

RE: [Doxygen-users] DOT Tool for windows

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

I have just sent the bug report to the Graphviz guys with
the following example

digraph inheritance
{
  rankdir=LR;
  Node145 [shape="box",label="CDirectorManagerImpl",
           fontsize=10,height=0.23];
}

When you store it inside a.dot and run the dot 1.7.6 beta 1
for Windows this way: 

  dot -Tgif a.dot -o a.gif

you can observe not only the cut top line, but cut also in the
way that shows that the line is not perfectly horizontal.
It can be also read from the PostScript output. I guess that
the the problems of the line cutting and horizontality
are related.  Moreover, it is clear that this bug is not caused 
by Doxygen and cannot (and should not) be adjusted by Doxygen.

For your information, I did not sent any bug report that uses 
doxfont, because I do not know how to work properly
with fonts in dot. Feel free to experiment and report with the
following example which was generated by Doxygen:

digraph inheritance
{
  rankdir=LR;
  Node145 [shape="box",label="CDirectorManagerImpl",fontsize=10,
                 height=0.2,width=0.4,fontname="doxfont",
                 color="black",URL="$classCDirectorManagerImpl.html"];
}

With regards,

Petr

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

> -----Original Message-----
> From:	Dimitri van Heesch [SMTP:di...@st...]
> Sent:	Monday, June 11, 2001 8:20 PM
> To:	dox...@li...
> Subject:	Re: [Doxygen-users] DOT Tool for windows
> 
> On Mon, Jun 11, 2001 at 10:41:24PM +0800, Jerzy Kaczorowski wrote:
> > Hi,
> > 
> > The notice about Graphviz 1.5 is not so obsolete, because the graphs
> > generated with new dot are even more broken than 1.5. E.g. 1.5 was only
> > cutting the tops of the boxes while new one is also mis-calculating the
> text
> > size so the text goes out of the box on the right (boxes too small).
> Looks
> > quite bad :(
> 
> Just to be clear: these are bugs in dot, not doxygen.
> 
> > It is so bad that if they pull down 1.5 it will probably make no sense
> to
> > use doxygen on windows any more without some archive to keep 1.5.
> > I wonder if doxygen could not make some adjustments to allow more space
> for
> > the boxes to accomodate for the problem - it is not only on windows from
> > what I know, even thought it seems to work better on Linux.
> 
> If this is the case, then I suggest to 
> 1) subscribe to the graphviz mailing list
>    see http://www.research.att.com/sw/tools/graphviz/doc/gvizfaq.html
> 2) create a broken dot graph using doxygen with DOT_CLEANUP set to NO,
>    and package this into a self contained example (dot graph + gif image +
>    doxfont.ttf + description what is wrong).
> 3) send it to the mailing list. I found the authors of graphviz very
>    willing to help.
> 
> Don't complain on this list if dot is not working properly, since I 
> cannot do much about it.
> 
> Regards,
>   Dimitri
> 
> 
> 
> _______________________________________________
> Doxygen-users mailing list
> Dox...@li...
> http://lists.sourceforge.net/lists/listinfo/doxygen-users

[Doxygen-users] Problem with group documentation

[Holger M. <hmu...@si...>]

Hi,

I think there went something wrong with the group documentation. I use
the following code:
-----------------------------
/**
 * @name Einstellung der Timer bzgl. CGMXCLK
 *
 * Folgende Werte muessen zur Timer Programmierung eingestellt werden:
 * (der Rest wird berechnet)
 *      - CGMXCLK  : externer CPU clock
 *      - TIM_A_PS : Prescaler des TIM A
 *      - TIM_A_TIM: TIM A overflow Zeit [s] <br>
 *                   (VORSICHT: Keine Bereichspruefung!!!!)
 *      - TIM_B_PS : Prescaler des TIM B
 *      - TIM_B_TIM: TIM B overflow Zeit [s] <br>
 *                   (VORSICHT: Keine Bereichspruefung!!!!)
 */
//@{
#define CGMXCLK   8000000       ///< 8 MHz externer CPU clock des CGM
#define CGMOUT    (CGMXCLK/2.0) ///< im User-Mode des CGM: CGMXCLK / 2
#define BUS_CLOCK (CGMOUT/2.0)  ///< im SIM: CGMOUT / 2
//@}
-----------------------------

And get this HTML output:
-----------------------------
Einstellung der Timer bzgl. CGMXCLK

Folgende Werte muessen zur Timer Programmierung eingestellt werden: (der =
Rest wird berechnet) * - CGMXCLK : externer CPU clock * - TIM_A_PS : Pres=
caler des TIM A * - TIM_A_TIM: TIM A overflow Zeit [s] <br> (VORSICHT: Ke=
ine Bereichspruefung!!!!) * - TIM_B_PS : Prescaler des TIM B * - TIM_B_TI=
M: TIM B overflow Zeit [s] <br> (VORSICHT: Keine Bereichspruefung!!!!)

-----------------------------

The group documentation still consists the HTML commands as well as
asterixes (*) and the minus "-" was not translated to an itemize list.

Holger
-- =

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
Holger M=FCller, Dipl.-Ing.                          Tel: +49/7034/92584-=
77
Abt. DOTE - Entwicklung                            Fax: +49/7034/92584-99=

sitronic GmbH
Robert-Bosch-Str. 9                          eMail: hmu...@si...=

D-71116 Gaertringen                          URL: http://www.sitronic.com=

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

Re: [Doxygen-users] Doxygen testing (was: hide undocumented enums)

[Peter S. <pet...@hu...>]

On Mon, 11 Jun 2001 21:22:43 +0200, Dimitri van Heesch wrote:

>> Another, simpler possibility would be a collection of input files and
>> approved output files to compare to with 'diff' each time a code
>> change is made. To automate these tests shell scripts or dedicated
>> tools like dejagnu could be used.

> I think this would make the tests rather fragile. If I tweak something
> on the output (for instance use a table instead of a list somewhere) 
> that would invalidate all tests. Another problem is how to verify that the
> generated diagrams contain the correct information.

When postprocessing the HTML files (perhaps with lynx or some other
tool) and thus extracting only the textual information, these diffs
could surely be made fairly robust. But I agree that basing on XML
sounds like a more optimal approach...

Regards

Peter
-- 
    _   _        Peter Steiner <pet...@hu...>
  / /_/ /        Hug-Witschi AG <http://www.hugwi.ch/>
 /  _  /         Electronic Engineering
/_/ /_/  _   _   Industriestrasse 12
   / / / / / /   CH-3178 Boesingen
  / /_/ /_/ /    Tel  +41 31 740 44 44
 /_ _ _ _ _/     Fax  +41 31 740 44 45

RE: [Doxygen-users] Doxygen testing (was: hide undocumented enums)

[Jens-A. R. <fl...@un...>]

> Since I am myself a 9 year full time programmer, I fully understand your
> problems.
> I find Doxygen very very helpfull in my case. And ok, sometimes there
> are bugs, but for
> a free product, no one can complain about this. I am one of the people
> that is very happy about Doxygen!
>
> Olaf

Me, too!

Just in case my last posting sounded as doxygen lacks too many features or
something like that (which is not the case):

My comment about extending the XML output to solve a lot of different
issues is just a suggestion for further development where everyone would
benefit in the long run (even Dimitri himself - since some
dependencies should be eleminated and testing becomes easier).

Doxygen is a very useful, feature rich tool the way it is and I am glad I
finally found it.

Jens

RE: [Doxygen-users] Doxygen testing (was: hide undocumented enums)

[Olaf B. <ola...@sk...>]

Hi Dimitri

>Most of these happen because=20
>1) I'm restructuring things and
>2) Things are a quite fragile (this is many because of the loosly
parsing
>   using flex, which is both a good and a bad thing.)
>3) I (can) only do limited testing.

Since I am myself a 9 year full time programmer, I fully understand your
problems.
I find Doxygen very very helpfull in my case. And ok, sometimes there
are bugs, but for
a free product, no one can complain about this. I am one of the people
that is very happy about Doxygen!

Olaf

RE: [Doxygen-users] Doxygen testing (was: hide undocumented enums )

[Trevor R. <Tre...@pe...>]

I agree.  The key to testability is componentization, and separate C++->XML,
XML->HTML, XML->RTF, XML->tex, and XML->man components are much easier to
test than a single C++->HTML/etc component.  They are even easier to test
than C++->"internal data structures" and "internal data
structures"->HTML/etc components.

Of course this really makes one wish that GCC-XML had a stable release.
However, I imagine that Doxygen could easily have full intermediate XML long
before that.  (Especially since GCC-XML is based on GCC 3.0, which is an
elusive release as well.)

-Trevor


-----Original Message-----
From: Jens-A. Reinhardt [mailto:fl...@un...]
Sent: Monday, June 11, 2001 3:04 PM
To: dox...@li...
Subject: Re: [Doxygen-users] Doxygen testing (was: hide undocumented
enums)



> Maybe verification on the XML output level would be more robost, but
> with the current XML output a lot of information would be missed.
>
> So, any ideas are welcome!

...and what about expanding the XML output?

It would help realizing the needs of a lot of of doxygen users.

Let it be the ones looking for more .css options or fancy design stuff,
the ones that need to add other (non doxygen) content, those who want to
add, drop, rearrange the output, or it would even help testing as you
suggested yourself. Everything could be done without touching the core
code and without the chance of messing up your code.

But I saw that letting XML become an intermediate format is on your todo
list with a rather high difficulty number. However, I guess it would
simplify a lot of things once established and the new modularity will
enable others to contribute more easily and help further development.

Jens





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

Re: [Doxygen-users] Doxygen testing (was: hide undocumented enums)

[Jens-A. R. <fl...@un...>]

> Maybe verification on the XML output level would be more robost, but
> with the current XML output a lot of information would be missed.
>
> So, any ideas are welcome!

...and what about expanding the XML output?

It would help realizing the needs of a lot of of doxygen users.

Let it be the ones looking for more .css options or fancy design stuff,
the ones that need to add other (non doxygen) content, those who want to
add, drop, rearrange the output, or it would even help testing as you
suggested yourself. Everything could be done without touching the core
code and without the chance of messing up your code.

But I saw that letting XML become an intermediate format is on your todo
list with a rather high difficulty number. However, I guess it would
simplify a lot of things once established and the new modularity will
enable others to contribute more easily and help further development.

Jens

[Doxygen-users] Doxygen testing (was: hide undocumented enums)

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

On Mon, Jun 11, 2001 at 04:49:18PM +0200, Volker Boerchers wrote:
> Hi all,
> 
> we see statements like this
> 
> [Peter Steiner]
> > I get undocumented #defines in the documentation (introduced somewhere
> > since 1.2.4 [I skipped 1.2.5 and 1.2.6, but 1.2.7, 1.2.8 and 1.2.8.1 all
> > have this bug]).
> 
> quite often in the last months in this list and i've the impression
> that they are still getting more. It seems as if most reported bugs
> are features that were added in version XXX but disappeared again in
> version XYZ.

Most of these happen because 
1) I'm restructuring things and
2) Things are a quite fragile (this is many because of the loosly parsing
   using flex, which is both a good and a bad thing.)
3) I (can) only do limited testing.

> This sounds as if there should be a regression test suite to protect
> the great features that doxygen provides from disappearing
> while adding further features. (As far as i can see no tests are part
> of the doxygen sources.)

That would certainly be nice.

> I have some experience with the great CppUnit test framework (see
> http://sourceforge.net/projects/cppunit, a port of JUnit) but i think
> it would be too much work to instrument doxygen with more or less
> complete unit tests.
> 
> Another, simpler possibility would be a collection of input files and
> approved output files to compare to with 'diff' each time a code
> change is made. To automate these tests shell scripts or dedicated
> tools like dejagnu could be used.

I think this would make the tests rather fragile. If I tweak something
on the output (for instance use a table instead of a list somewhere) 
that would invalidate all tests. Another problem is how to verify that the
generated diagrams contain the correct information.

Maybe verification on the XML output level would be more robost, but
with the current XML output a lot of information would be missed.

So, any ideas are welcome!

Regards,
  Dimitri

[Doxygen-users] Problems with in.2.8.1 with external tagfiles

[Abhinandan J. <Abh...@jp...>]

Hi

I just switched over from Doxygen 1.2.6 to 1.2.8.1. I use external
tagiles quite a bit in my documentation. However, with 1.2.8.1 I am
starting to see a lot of warning messages of the form 

doxy-Dvalue.tag:/home/soa/dev/users/jain/builds/Dshell-main/src/Dvalue/DebugLogCIF.cc:1: Warning: member DebugLog_Init of class DebugLogCIF.cc cannot be found
doxy-Dvalue.tag:/home/soa/dev/users/jain/builds/Dshell-main/src/Dvalue/DebugLogCIF.cc:1: Warning: member DebugLogInit of class DebugLogCIF.cc cannot be found
doxy-Dvalue.tag:/home/soa/dev/users/jain/builds/Dshell-main/src/Dvalue/DebugLogCIF.cc:1: Warning: member DebugLogIsInitialized of class DebugLogCIF.cc cannot be found
doxy-Dvalue.tag:/home/soa/dev/users/jain/builds/Dshell-main/src/Dvalue/DebugLogCIF.cc:1: Warning: member DebugLogSetMsgBufSize of class DebugLogCIF.cc cannot be found

etc. etc.

Here doxy-Dvalue.tag is the external tag file. I get these warning lines for
each member entry in the tagfile. Also DebugLogCIF.cc is a file and not
a class so the warning messages do not make sense either.

I did not have this problem with 1.2.6.

Thanks in advance for your help.

Abhi

Re: [Doxygen-users] DOT Tool for windows

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

On Mon, Jun 11, 2001 at 10:41:24PM +0800, Jerzy Kaczorowski wrote:
> Hi,
> 
> The notice about Graphviz 1.5 is not so obsolete, because the graphs
> generated with new dot are even more broken than 1.5. E.g. 1.5 was only
> cutting the tops of the boxes while new one is also mis-calculating the text
> size so the text goes out of the box on the right (boxes too small). Looks
> quite bad :(

Just to be clear: these are bugs in dot, not doxygen.

> It is so bad that if they pull down 1.5 it will probably make no sense to
> use doxygen on windows any more without some archive to keep 1.5.
> I wonder if doxygen could not make some adjustments to allow more space for
> the boxes to accomodate for the problem - it is not only on windows from
> what I know, even thought it seems to work better on Linux.

If this is the case, then I suggest to 
1) subscribe to the graphviz mailing list
   see http://www.research.att.com/sw/tools/graphviz/doc/gvizfaq.html
2) create a broken dot graph using doxygen with DOT_CLEANUP set to NO,
   and package this into a self contained example (dot graph + gif image +
   doxfont.ttf + description what is wrong).
3) send it to the mailing list. I found the authors of graphviz very
   willing to help.

Don't complain on this list if dot is not working properly, since I 
cannot do much about it.

Regards,
  Dimitri

[Doxygen-users] rtfonly

[Johann M. <joh...@pd...>]

Hi,

I am fairly new to doxygen and have the following question/sugestion:

I am using aliases together with \htmlonly ... \endhtmlonly
in the configuration file to define special commands.
Of course, this works only with html output. 

It would be nice, to have a \rtfonly ... \endrtfonly for
rtf output. At the moment I use two configuration files,
one for rtf and one for html as workaround.

Any other sugestions?

Kind regards,
J.M.


----------------------------------------------------------
Dr. Johann Marinits         eMail: Joh...@pd...
PDTS - Prozessdatentechnik und Systeme
Gesellschaft fuer industrielle Datenverarbeitung Ges.m.b.H
A-1150 Wien, Moeringgasse 20, Austria
Tel.:  +43 (1) 526 17 57-240   Fax.: +43 (1) 526 17 57-199
http://www.pdts.at 
---------------------------------------------------------- 

[Doxygen-users] New problems in 1.2.8.1

[Trevor R. <Tre...@pe...>]

Hello,

I'm getting some new warnings from 1.2.8.1 that have not occurred in the
past (at least with 1.2.7 and before).

First, I have a lot of grouped C functions in one project, and I'm using a
tag file to import them into another project.  However, I get a warning like
this for each one (there are a few hundred):

<unknown>:1: Warning: member PSRWLockCreate of class ps_sync_rwlock cannot
be found

"ps_sync_rwlock" is a group, not a class:

/**
 * @defgroup ps_sync_rwlock Reader/Writer Locks
 * @ingroup ps_sync
 * @{
 */

/**
 * Creates a reader/writer lock object.
 */
PSCORE_STDAPI PSRWLockCreate(PS_PCASTR pszName, PS_UINT uiFlags, PS_HANDLE
*phRWLock);

...

/** @} */

I haven't noticed any problems from this yet, but it is strange.

Second, I'm getting warnings from template specializations (this has nothing
to do with tag files):

D:/psvcs2/comp/pscl/include/pscomptr.h:134: Warning: no matching class
member found for
  CPSComPtr< IPSUnknown, IPSUnknown >::CPSComPtr::CPSComPtr()
D:/psvcs2/comp/pscl/include/pscomptr.h:139: Warning: no matching class
member found for
  CPSComPtr< IPSUnknown, IPSUnknown >::CPSComPtr::CPSComPtr(const CPSComPtr<
PtrClass, UnkClass > & ptr)
(...and so on for every member)

Note the extra "CPSComPtr::".  Here's part of the class definition:

template <>
class CPSComPtr<IPSUnknown, IPSUnknown> : public CPSSmartPtr<IPSUnknown>
{
    typedef IPSUnknown PtrClass;
    typedef IPSUnknown UnkClass;
    typedef CPSSmartPtr<IPSUnknown> BaseClass;

public:
    CPSComPtr() : BaseClass() { }

    CPSComPtr(const CPSComPtr<PtrClass, UnkClass>& ptr) : BaseClass(ptr) { }
...
}

Once again, everything seems to work, I just get lots of extraneous errors.

Thanks,
Trevor

Re: [Doxygen-users] hide undocumented enum

[Volker B. <boe...@we...>]

Hi all,

we see statements like this

[Peter Steiner]
> I get undocumented #defines in the documentation (introduced somewhere
> since 1.2.4 [I skipped 1.2.5 and 1.2.6, but 1.2.7, 1.2.8 and 1.2.8.1 all
> have this bug]).

quite often in the last months in this list and i've the impression
that they are still getting more. It seems as if most reported bugs
are features that were added in version XXX but disappeared again in
version XYZ.

This sounds as if there should be a regression test suite to protect
the great features that doxygen provides from disappearing
while adding further features. (As far as i can see no tests are part
of the doxygen sources.)

I have some experience with the great CppUnit test framework (see
http://sourceforge.net/projects/cppunit, a port of JUnit) but i think
it would be too much work to instrument doxygen with more or less
complete unit tests.

Another, simpler possibility would be a collection of input files and
approved output files to compare to with 'diff' each time a code
change is made. To automate these tests shell scripts or dedicated
tools like dejagnu could be used.

What do you think about doxygen & tests?

Volker
-- 
Volker Boerchers
boe...@we...

Re: [Doxygen-users] DOT Tool for windows

[Jerzy K. <je...@wn...>]

Hi,

The notice about Graphviz 1.5 is not so obsolete, because the graphs
generated with new dot are even more broken than 1.5. E.g. 1.5 was only
cutting the tops of the boxes while new one is also mis-calculating the text
size so the text goes out of the box on the right (boxes too small). Looks
quite bad :(

It is so bad that if they pull down 1.5 it will probably make no sense to
use doxygen on windows any more without some archive to keep 1.5.
I wonder if doxygen could not make some adjustments to allow more space for
the boxes to accomodate for the problem - it is not only on windows from
what I know, even thought it seems to work better on Linux.

Best Regards,
Jerzy

----- Original Message -----
From: "Prikryl,Petr" <PRI...@sk...>
To: <dox...@li...>
Sent: Monday, June 11, 2001 5:12 PM
Subject: RE: [Doxygen-users] DOT Tool for windows


> Hi Roland,
>
> Roland Schwab wrote...
> > From where can I get the graphical visualization toolkit (DOT-Tool) for
> > Doxygen running under Windows ??
>
> As stated in the Doxygen documentation (Graphs and diagrams), the dot
> tool can be downloaded from
http://www.research.att.com/sw/tools/graphviz/.
> More precisely, the
> http://www.research.att.com/sw/tools/graphviz/download.html
> is the download page.
>
> The Graphviz 1.7.6 beta 1 for Windows is available now (the notice about
> version 1.5 in Doxygen documentation is slightly obsolete).  I personally
> did not observe any serious problem with the beta version from Doxygen
> -- except the cut top line of some boxes (I do not know if it is the
Doxygen
> problem or the dot problem).
>
> With regards,
>
> Petr
>
> --
> Petr Prikryl, SKIL, spol. s r.o., pri...@sk...
>
>
> _______________________________________________
> Doxygen-users mailing list
> Dox...@li...
> http://lists.sourceforge.net/lists/listinfo/doxygen-users
>

RE: (off-topic) RE: [Doxygen-users] Documenting IDL

[Stephen G. <ste...@cl...>]

> -----Original Message-----
> From: dox...@li...
> [mailto:dox...@li...]On Behalf 
> Of Victor A.
> Wagner, Jr.
> Sent: 11 June 2001 13:18
> To: dox...@li...
> Subject: RE: (off-topic) RE: [Doxygen-users] Documenting IDL
> 
> 
> or use void* like I ORIGINALLY suggested (and is suggested by 
> looking at 
> how the STL does it with iterators.
> 

Which is one of the items that was covered by the last sentence:

> >
> >The suggestions - _all_ of them - all have their merits and 
> all can all work
> >extremely well...
> 

You pays your money and takes your choice.

Re: [Doxygen-users] hide undocumented enum

[Peter S. <pet...@hu...>]

I have observed a similar problem as David...

On Fri, 08 Jun 2001 15:18:21 +0200, dav...@ca... wrote:

>  EXTRACT_ALL            = NO
>  EXTRACT_PRIVATE        = NO
>  EXTRACT_STATIC         = NO
>  HIDE_UNDOC_MEMBERS     = YES
>  HIDE_UNDOC_CLASSES     = YES

> After generation the undocumented structures are not in the html
> documentation but the undocumented enumarates appears.

I get undocumented #defines in the documentation (introduced somewhere
since 1.2.4 [I skipped 1.2.5 and 1.2.6, but 1.2.7, 1.2.8 and 1.2.8.1 all
have this bug]).

A similar problem (but already present in 1.2.4): some undocumented, but
initialized arrays appear in the output.

If still needed to reproduce, I could try to provide a stripped down
example.

Regards

Peter
-- 
    _   _        Peter Steiner <pet...@hu...>
  / /_/ /        Hug-Witschi AG <http://www.hugwi.ch/>
 /  _  /         Electronic Engineering
/_/ /_/  _   _   Industriestrasse 12
   / / / / / /   CH-3178 Boesingen
  / /_/ /_/ /    Tel  +41 31 740 44 44
 /_ _ _ _ _/     Fax  +41 31 740 44 45

RE: (off-topic) RE: [Doxygen-users] Documenting IDL

[Victor A. W. Jr. <va...@ru...>]

or use void* like I ORIGINALLY suggested (and is suggested by looking at 
how the STL does it with iterators.

At Monday 2001/06/11 09:37, you wrote:

> > -----Original Message-----
> > From: dox...@li...
> > [mailto:dox...@li...]On Behalf Of Hendrik
> > Schober
> > Sent: 10 June 2001 20:58
> > To: dox...@li...
> > Subject: Re: (off-topic) RE: [Doxygen-users] Documenting IDL
> >
> >
> > "Stephen Goudge" <ste...@pi...> wrote:
> >
> > > [...]
> > > I did originally have an operator int() that could be used
> > in if-statements,
> > > which worked fine using VC++2 through to VC++4; then a
> > client bought VC++5 and
> > > it became ambiguous (I forget the precise reason why), so
> > everything switched to
> > > IsValid() from then on.
> >
> >   'int' seems like one of the most troublesome ideas.
> >   (What's 'spa+spb' to become then?)
> >
> > > [...]
> > > Even with a decent compiler, there is the vexed question of
> > what the cast
> > > operator should be casting _to_ - you don't really want to
> > return another
> > > pointer type, as that looks too much like you're providing
> > a backdoor. These
> > > days, 'bool' would be a reasonable choice (now that the
> > compilers actually
> > > support 'bool'). The best choice would be the mythical
> > 'logical' type that 'if',
> > > 'while' etc use, but that isn't available :-(
> >
> >   Oh, but that's available: It's named 'bool'.
>
>The "the mythical 'logical' type that 'if', 'while' etc use" is not 'bool' - I
>suppose you could produce a parser that used bool there, but just taking a 
>straw
>poll around the office, the guy sitting next to me (working on a C compiler)
>uses 'long int' for 'if' etc, which is what the Standard says you do 
>(hence the
>use of operator int() to feed 'if' in the oldest code). Meanwhile, in my
>program, a C-expression evaluator has a type 'logical' that is only used
>internally (ie, from the point of view of someone writing an expression to be
>evaluated, is mythical because you can not declare anything to have type
>'logical') and lives at the very opposite end of the automatic type promotion
>ladder from 'bool'.
>
>Also, unfortunately, all that time ago, 'bool' was not available in all the
>compilers being used :-(
>
> >   But 'bool' isn't all that good either, because it's an
> >   arithmetic type. (Or was it convertible into one?)
> >   You could thus write 'sp+5' and get funny results.
>
><snip>
>
>That points out the problem exactly - all of the types that you can use here
>already have well-known meanings and tend to imply that it is possible to use
>them in expressions _other_ than just 'if'. No matter what you choose, you can
>write something that will give funny results.
>
>Hence (not to be taken too seriously) wish to be able to use a type, 
>'logical',
>that does not carry any such baggage, based on the fact that I _know_ such a
>type does/can live deep within the bowels of a compiler.
>
>The _only_ answer I know of that is possible to implement _and_ totally 
>free of
>any such baggage is an "IsValid()" method - which is right back to where we
>started.
>
> >   In his book "Modern C++ Design" Andrei Alexandrescu
> >   discusses this issue. His idea (typing from memory):
> >
> >   template<class T>
> >   class SmartPtr {
> >     private:
> >       class Tester {
> >         void operator delete(void*);
> >       };
> >     public:
> >       operator Tester*() const
> >       {
> >         if( !IsValid() )
> >           return NULL;
> >         static Tester tester;
> >         return tester;
> >       }
> >       // ...
> >   };
> >
> >   (The private 'operator delete()' is there to prevent
> >   users from trying to delete the result of calling the
> >   convertion operator.)
> >
> >   I have not used this yet, so I don't know whether it's
> >   really as great an idea as it seemed to me.
> >
> > > Stephen Goudge
> >
> >   Schobi
>
>Aha, yet another approach :-)
>
>The suggestions - _all_ of them - all have their merits and all can all work
>extremely well, but, just like the search the One True String Class, there 
>is no
>absolute best answer to this. Shame really.
>
>Now, back to Doxygen...
>
>Stephen Goudge
>
>
>
>_______________________________________________
>Doxygen-users mailing list
>Dox...@li...
>http://lists.sourceforge.net/lists/listinfo/doxygen-users

Victor A. Wagner, Jr.
PGP RSA fingerprint = 4D20 EBF6 0101 B069 3817 8DBF C846 E47A
PGP D-H fingerprint = 98BC 65E3 1A19 43EC 3908 65B9 F755 E6F4 63BB 9D93
The five most dangerous words in the English language:
               "There oughta be a law"