Russian translation update

Italian translation update

Here is the intalian translation updated to include the new trDeprecatedList
method.

Cheers
Alessandro

Visual C++ 6, the latest CVS release, and CodeWarrior integration

Hi Doxygenators,

I just got the new CVS release and tried to compile it with VC++6
on Windoze2k, and got the following error messages when I ran the
make.bat script:

c:\dev\doxygen-1.2.17\src\ce_parse.cpp(337) : error C2620: union 'yyalloc' : member 'yyvs' has
user-defined constructor or non-trivial default constructor
c:\dev\doxygen-1.2.17\src\ce_parse.cpp(784) : error C2039: 'yyvs' : is not a member of 'yyalloc'
        c:\dev\doxygen-1.2.17\src\ce_parse.cpp(335) : see declaration of 'yyalloc'

I worked around this by copying that source file from the
previous doxygen release:

cp ../doxygen-1.2.16/src/ce_parse.cpp src/ce_parse.cpp

This got it to build from the command line. I don't know if I have
broken anything by doing so but it seems superficially OK. Maybe
a flex/bison devotee can explain what's going on? The ce_parse.cpp
file is being generated automagically. It's also possible that the 
'problem' is in Risible (sic) C++6. Has anyone else tried this recently?

In any case,  I needed to add the following to the project file to get 
it to build from the VC++6 IDE:

src\docparser.cpp
src\docparser.h
src\doctokeniser.h
src\doctokeniser.cpp
src\cmdmapper.cpp
src\cmdmapper.h

I attach an updated DSP file which encapsulates these additions. Note
that you still need to run 'make msvc' once from the command line
before the IDE build will work. That's because VC++6 does not know
how to parse the flex and bison files that generate some of the C source
that needs to be compiled (and I don't know how to tell it to do so . 
Once you've run that make once, you can build variants from the IDE 
as long as you have not changed any of the flex and bison data files.

Cheers

Simon Goodwin
Technology Programmer, ATD

P.S. if any of you have to use or support Metrowerks's CodeWarrior you
may like to know a way to integrate Doxygenated helpfile documentation
into their IDE (similar to the MSDNIntegrator for DevStudio - I have had
no replies to my request for an equivalent for VC++7 (aka .NET), sadly).

We have just persuaded Metrowerks to add support for third-party helpfiles
and although it is not part of the release yet, it does work and we (ATD and
Metrowerks) are looking for testers. Contact me if you'd like to know more.

--

-- 
Simon Goodwin <simon.goodwin <at> atd.co.uk>

Re: Visual C++ 6, the latest CVS release, and CodeWarrior integration

On Tue, Aug 06, 2002 at 12:01:23PM +0100, Simon Goodwin wrote:
> Hi Doxygenators,
> 
> I just got the new CVS release and tried to compile it with VC++6
> on Windoze2k, and got the following error messages when I ran the
> make.bat script:
> 
> c:\dev\doxygen-1.2.17\src\ce_parse.cpp(337) : error C2620: union 'yyalloc' : member 'yyvs' has
user-defined constructor or non-trivial default constructor
> c:\dev\doxygen-1.2.17\src\ce_parse.cpp(784) : error C2039: 'yyvs' : is not a member of 'yyalloc'
>         c:\dev\doxygen-1.2.17\src\ce_parse.cpp(335) : see declaration of 'yyalloc'
> 
> I worked around this by copying that source file from the
> previous doxygen release:
> 
> cp ../doxygen-1.2.16/src/ce_parse.cpp src/ce_parse.cpp

From the manual:

Bison problems 

"
Versions 1.31 to 1.34 of bison contain a "bug" that results in 
a compiler errors like this: 

ce_parse.cpp:348: member `class CPPValue yyalloc::yyvs' with 
constructor not allowed in union 

This problem has been solved in version 1.35 
(versions before 1.31 will also work). 
"

i.e. time to upgrade bison.

> This got it to build from the command line. I don't know if I have
> broken anything by doing so but it seems superficially OK. Maybe
> a flex/bison devotee can explain what's going on? The ce_parse.cpp
> file is being generated automagically. It's also possible that the 
> 'problem' is in Risible (sic) C++6. Has anyone else tried this recently?
> 
> In any case,  I needed to add the following to the project file to get 
> it to build from the VC++6 IDE:
> 
> src\docparser.cpp
> src\docparser.h
> src\doctokeniser.h
> src\doctokeniser.cpp
> src\cmdmapper.cpp
> src\cmdmapper.h

For completeness could you please also include:
  src\docvisitor.h
  src\printdocvisitor.h

> I attach an updated DSP file which encapsulates these additions. Note
> that you still need to run 'make msvc' once from the command line
> before the IDE build will work. That's because VC++6 does not know
> how to parse the flex and bison files that generate some of the C source
> that needs to be compiled (and I don't know how to tell it to do so . 
> Once you've run that make once, you can build variants from the IDE 
> as long as you have not changed any of the flex and bison data files.
> 
> Cheers
> 
> Simon Goodwin
> Technology Programmer, ATD
> 
> P.S. if any of you have to use or support Metrowerks's CodeWarrior you
> may like to know a way to integrate Doxygenated helpfile documentation
> into their IDE (similar to the MSDNIntegrator for DevStudio - I have had
> no replies to my request for an equivalent for VC++7 (aka .NET), sadly).

Maybe not too many people are already using VC++ for various reasons 
(I am one those people). Nice to see you are working on CodeWarrior support
though.

Regards,
  Dimitri

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: [Doxygen-users] Avoiding repeated documentation on inherited members?

On Wed, Aug 07, 2002 at 10:02:25AM +0200, Morten Eriksen wrote:
> Hi,
> 
> I wondering if it's possible to configure Doxygen to _not_ repeat the
> documentation on C++ inherited members of subclasses?
> 
> IMHO, this feature tends to clutter up the API documentation more than
> it clarifies -- at least for the particular class library I'm
> documenting.
> 
> An example to make myself clear:
> 
> ----8<--- [snip] ---------8<--- [snip] ---------8<--- [snip] -----
> 
> //! This class blablabla...
> class Super {
> public:
>         //! This method blablabla...
>         virtual void aVirtualMethod(void);
> };
> 
> //! This class blablabla...
> class Sub : class Super {
> public:
>         virtual void aVirtualMethod(void);
> };
> 
> ----8<--- [snip] ---------8<--- [snip] ---------8<--- [snip] -----
> 
> Now, for class Sub, aVirtualMethod() will be included in the
> documentation, just repeating the documentation of this method in the
> Super class. I would like to avoid that, to "clean up" and remove
> unnecessary clutter in a huge, fine-grained class library I have
> documented here. This library has deeply nested class inheritance
> hierarchies, with many virtual methods like that above primarily used
> internally in the library implementation. Having the method
> documentation repeated for each subclass which overrides the virtual
> method of the superclass therefore just generates "noise".
> 
> So, is there any way to accomplish this -- ie don't include overridden
> methods in the output _if_ they just use the doc of the same method in
> the superclass?

INHERIT_DOCS = NO should do that if I understand you correctly.

Regards,
  Dimitri

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Have a look at the project related to UML diagrams through dot to ol

Hi,

Stefan Seefeld (the competing Synopsis project) posted
the following reference to the Synopsis mailing list:

  http://www.spinellis.gr/sw/umlgraph/

The UMLGraph project by Diomidis D. Spinellis is written
in Java for JavaDoc and the dot tool (about 10KB of source 
text).  It is freely available, but copyrighted.  It probably
should be recorded in doxygen todo list.  I guess that
some users really wish to have UML diagrams generated
by doxygen.

Regards,
  Petr

--

-- 
Petr Prikryl, Skil, spol. s r.o., (prikrylp <at> skil.cz)

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: Re: [Doxygen-users] Avoiding repeated documentation on inherited members?

* Morten
> So, is there any way to accomplish this -- ie don't include
> overridden methods in the output _if_ they just use the doc of the
> same method in the superclass?

* Dimitri
> INHERIT_DOCS = NO should do that if I understand you correctly.

That's what I thought too from reading the Doxygen documentation, but
there are two major inconveniences of how that works:

        - the inherited/overridden methods are *still* present in the
          output, but only for the class reference summary at the top
          (which I would still like to avoid to have minimal clutter
          for the application programmer who's using the library API)

        - Doxygen suddenly spews out a zillion warnings for all the
          undocumented, inherited/overridden methods

(Actually, there doesn't seem to be any real advantage to using
INHERIT_DOCS=NO in any setting..? Is this perhaps because the
drawbacks mentioned above are bugs?)

Best regards,
Morten

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

[PATCH] Fix for Doxygen warning on private members

Hi,

I reported a problem last week about Doxygen spitting out warnings
about missing documentation for private members in certain cases. The
particular case I was seeing is when you hide a "friend class"
statement inside the private block of a C++ class declaration, like
this:

  ---8<--- [snip] -------8<--- [snip] -------8<-
  class MyClass {
     // [...]

  private:
    friend class MyHiddenImplementationClass;
  };
  ---8<--- [snip] -------8<--- [snip] -------8<-

..then Doxygen will complain about missing doc on
MyHiddenImplementationClass, even though EXTRACT_PRIVATE=NO.

Here's a patch from my colleague Kristian Eide that will take care of
the problem:

--- memberdef.cpp	Tue Aug 13 10:05:39 2002
+++ ../../doxygen-1.2.17/src/memberdef.cpp	Tue Aug 13 09:57:34 2002
 <at>  <at>  -1519,7 +1519,8  <at>  <at> 
     t="file", d=fd;

   if (d && d->isLinkable() && !isLinkable() && !isDocumentedFriendClass()
-      && name().find(' <at> ')==-1)
+      && name().find(' <at> ')==-1 &&
+      (prot!=Private || Config_getBool("EXTRACT_PRIVATE")))
    warn_undoc(m_defFileName,m_defLine,"Warning: Member %s of %s %s is not documented.",
         name().data(),t,d->name().data());
 }

Best regards,
Morten

-------------------------------------------------------
This sf.net email is sponsored by: Dice - The leading online job board
for high-tech professionals. Search and apply for tech jobs today!
http://seeker.dice.com/seeker.epl?rel_code=31

[PATCH] Re: [Doxygen-users] Avoiding repeated documentation on inherited members?

Morten Eriksen <mortene <at> sim.no> writes:

> I wondering if it's possible to configure Doxygen to _not_ repeat
> the documentation on C++ inherited members of subclasses?

Replying to my own post here... anyway, I had a problem described like
this:

> IMHO, this feature tends to clutter up the API documentation more
> than it clarifies -- at least for the particular class library I'm
> documenting.
> 
> An example to make myself clear:
> 
> ----8<--- [snip] ---------8<--- [snip] ---------8<--- [snip] -----
> 
> //! This class blablabla...
> class Super {
> public:
>         //! This method blablabla...
>         virtual void aVirtualMethod(void);
> };
> 
> //! This class blablabla...
> class Sub : class Super {
> public:
>         virtual void aVirtualMethod(void);
> };
> 
> ----8<--- [snip] ---------8<--- [snip] ---------8<--- [snip] -----
> 
> Now, for class Sub, aVirtualMethod() will be included in the
> documentation, just repeating the documentation of this method in
> the Super class. I would like to avoid that, to "clean up" and
> remove unnecessary clutter in a huge, fine-grained class library I
> have documented here.

..and another problem described like this:

> [...] is it possible to configure Doxygen to not output
> non-documented default constructors and destructors of a C++ class?
> 
> The documentation for default constructors usually just ends up as
> 
>         //! Default constructor.
>         MyClass::MyClass(void) { [...] }
> 
> or
> 
>         //! Default constructor, initializes internal member variables.
>         MyClass::MyClass(void) { [...] }
> 
> and for the destructor
> 
>         //! Destructor, deallocates resources used by class instance.
>         MyClass::~MyClass() { [...] }
> 
> ..or something in this vein -- which of course is completely worthless
> to the application programmer, so it could just as well have been left
> out. *Not* documenting the default constructors and/or the destructor
> could be sufficient clue to Doxygen to don't bother with them for the
> output.
> 
> So, is there currently any way to leave out un-documented default
> constructors and destructors?

(Sorry for the lengthy quoting, I just wanted to rehash the problems
for the developers, as the mails were sent to the -users list.)

Now, I have a patch done by a colleague (Kristian Eide) which fixes
both problems, so please consider the following for inclusion (done
against the code of the 1.2.17 release):

----8<--- [snip] --------8<--- [snip] --------8<--- [snip] ----8<----

--- memberdef.cpp	Wed Jun 26 19:16:23 2002
+++ ../../doxygen-1.2.17/src/memberdef.cpp	Mon Aug 12 12:11:13 2002
 <at>  <at>  -581,8 +581,33  <at>  <at> 
                              mtype==Friend
                             );

+    // hide member if it overrides a member in a superclass and has no
+    // documentation
+    bool visibleIfDocVirtual = (reimplements() == NULL ||
+                                hasDocumentation()
+                               );
+
+    // true if this member is a constructor or destructor
+    // This should perhaps be included in the MemberDef class
+    bool cOrDTor = (name()==classDef->localName() ||         // constructor
+                    (name().find('~')!=-1 &&  // hack to detect destructor
+                     name().find("operator")==-1
+                    )
+                   );
+
+    // hide default constructors or destructors (no args) without
+    // documentation
+    bool visibleIfNotDefaultCDTor = !(cOrDTor &&
+                                     defArgList != NULL &&
+                                     (defArgList->isEmpty() ||
+                                      defArgList->first()->type == "void"
+                                     ) &&
+                                     !hasDocumentation()
+                                    );
+
     bool visible = visibleIfStatic && visibleIfDocumented && 
-                   visibleIfEnabled && visibleIfPrivate && !annScope;
+                   visibleIfEnabled && visibleIfPrivate &&
+                   visibleIfDocVirtual && visibleIfNotDefaultCDTor && !annScope;
     //printf("MemberDef::isBriefSectionVisible() %d\n",visible);
     return visible;
 }

----8<--- [snip] --------8<--- [snip] --------8<--- [snip] ----8<----

Best regards,
Morten

-------------------------------------------------------
This sf.net email is sponsored by: Dice - The leading online job board
for high-tech professionals. Search and apply for tech jobs today!
http://seeker.dice.com/seeker.epl?rel_code=31

[PATCH] Kill warnings on un-documented private compunds

Hi,

I have another patch, this time for the following problem, reported a
couple of weeks ago:

> I have an annoying problem with Doxygen (tested with released
> version 1.2.17). This declaration in a .h file:
> 
> ----8<---- [snip] ---------8<---- [snip] ---------8<---- [snip] -----
> 
> class MyClass {
> private:
>   struct ShouldNotBeDocumented {
>   };
> };
> 
> ----8<---- [snip] ---------8<---- [snip] ---------8<---- [snip] -----
> 
> ..will cause doxygen to emit the following warning:
> 
> <...>/private_struct.h:3: Warning: Compound MyClass::ShouldNotBeDocumented is not documented.
> 
> [...]
> 
> This seems like a bug to me, as the default value of EXTRACT_PRIVATE
> is "NO"?

Here is the patch (yet again done by my colleague Kristian Eide):

----8<---- [snip] -------8<---- [snip] -------8<---- [snip] ---
--- doxygen.cpp	Sun Jul 14 18:27:42 2002
+++ ../../doxygen-1.2.17/src/doxygen.cpp	Tue Aug 13 11:39:46 2002
 <at>  <at>  -3255,7 +3255,8  <at>  <at> 
         bName.right(2)!="::")
     {
       if (!root->name.isEmpty() && root->name[0]!=' <at> ' &&
-          (guessSection(root->fileName)==Entry::HEADER_SEC || Config_getBool("EXTRACT_LOCAL_CLASSES"))
+          (guessSection(root->fileName)==Entry::HEADER_SEC || Config_getBool("EXTRACT_LOCAL_CLASSES") &&
+          (root->protection!=Private || Config_getBool("EXTRACT_PRIVATE")))
          )
         warn_undoc(
                    root->fileName,root->startLine,
----8<---- [snip] -------8<---- [snip] -------8<---- [snip] ---

Best regards, 
Morten

-------------------------------------------------------
This sf.net email is sponsored by: Dice - The leading online job board
for high-tech professionals. Search and apply for tech jobs today!
http://seeker.dice.com/seeker.epl?rel_code=31