doxygen-users — List for users of doxygen

[Doxygen-users] Bug: K & R Style functions

[David H. <hi...@la...>]

Dimitri,

Doxygen can't handle (old) K & R C style functions. They are not ANSI
standard but many compilers will still compile them.

It's up to you to decide if this is a bug, or just not supported.

-Dave-

[Doxygen-users] how to find out which file is my function in?

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

Hi,

is there a way to modify the generated (HTML) documentation such that when I
find the documentation for a function, I can also find in which include file
it is declared?

e.g. I want to find out about a function. I go to the section "Namespace
members", look it up in the alphabetical list. I click on its namespace link
to find the documentation. fine. However, I don't see now whcih file this is
declared in, so I don't know which file I should include to be able to use
this function.

For classes, this is ok, as the class documentation contains a #include
statement.

Thanks

Kris Thielemans
(kris.thielemans <at> ic.ac.uk)
Imaging Research Solutions Ltd
Cyclotron Building
Hammersmith Hospital
Du Cane Road
London W12 ONN, United Kingdom

web site address: http://www.irsl.org/kris

[Doxygen-users] Bug: conditional sections in 1.2.12

[Phil E. <ped...@dm...>]

I have some doc blocks that look like this:

    /**
     *   Some general information.
     *
     *   @if maint
     *   Maintainer information.
     *   @endif
    */
    the entity (class, whatever) to be documented ....

This worked fine up until recently.  Now the conditionals are taking
over the entire documentation block!  If 'maint' is enabled everything
appears, but if 'maint' is not enabled, then /nothing/ appears, not even
the general information.  The entire class is considered undocumented by
doxygen, and no output is produced at all.

I'm using 1.2.12, as packaged by Debian unstable.  Previous versions did
not have this bug.

Phil

[Doxygen-users] Gift for those single-sourcing or API documentation projects

[Glenn M. <gle...@vo...>]

Howdy,

I just uploaded a file (tp_tools.zip 1.8 MB) to the HATT files area that
may be of interest to those creating large single-sourcing projects or
API documentation.

(If you're not part of HATT and are interested, let me know and I'll
send it to you directly. Or you can tell me/assist me in posting this
file to a location where others can access it.)

I do have my company's permission to open-source these tools.

Comments and suggestions are appreciated. However, I must be honest that
I have enough on my plate and am trying to get these out so that I can
move on to other more pressing projects at work. There's no guarantees
that I'll do anything further on the tools themselves.=20

Unzip and click on _start_here.html to see what is included. A short
summary is below.

Have fun.

Glenn Maxey
Technical Writer
Voyant Technologies, Inc.
1765 West 121st Avenue
Westminster, CO 80234-2301
Tel. +1 303.223.5164
Fax. +1 303.223.5275
gle...@vo...



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

The TechPubs Tools (TPT) pick up where other tools (Mif2Go/WWP,
Doxygen/JavaDoc) leave off. They are intended for both large
single-sourcing applications and/or API documentation.=20

TPT wraps around any number of mini-HTML systems and creates a
comprehensive HTML system complete with table of contents and an
auto-generated index/concordance. TPT consists of Perl programs, UNIX
shell scripts, and master template files (HTML).

Although designed for UNIX, the shell scripts can be easily altered to
batch files. Perl is supported on NT.

The tp_tools.zip file (1.8 MB) contains everything you need plus
complete documentation (using these tools on themselves).


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

The TechPubs Tools grew out of a need at Voyant Technologies, Inc. to
document our Application Programming Interface (API). Off-the-shelf
tools could only take us so far. The TechPubs Tools were developed to
bridge the gab between where those tools left off and where we wanted to
be.=20

The first version of our API manual was created using FrameMaker.
Unfortunately, it was a manual process to keep the API documentation in
sync with the code.=20

Doxygen is an off-the-shelf, open-source program that extracts the exact
code syntax and specially flagged comments directly from the source
code. It creates a mini-HTML documentation system for the code in a
project. (JavaDoc is a similar tool.)

After getting buy-off from our Software Development organization, we
migrated most of the API reference material from the FrameMaker
documents into appropriately marked comments in the source code. Doxygen
was able to get us 70% of the way towards our API reference
documentation.=20

Where Doxygen came up short:=20

- Our API consists of multiple projects, which means multiple mini-HTML
systems.=20

- Portions of the API documentation, such as overview and how-to
sections, still needed to be maintained and published from FrameMaker.

Mif2Go (from Omsys) is an inexpensive off-the-shelf tool that reliably
exports from FrameMaker into a variety of formats, including HTML. It,
too, creates a mini-HTML documentation system. (WebWorks Publisher is a
similar tool.)

The challenge for Voyant's Technical Publication Department was to wrap
all of these mini-HTML systems into one big HTML system. Hence the
home-grown tools that Voyant has given their permission for me to
open-source.


Glenn Maxey
Technical Writer
Voyant Technologies, Inc.
1765 West 121st Avenue
Westminster, CO 80234-2301
Tel. +1 303.223.5164
Fax. +1 303.223.5275
gle...@vo...

[Doxygen-users] Duplicate Declarations

[Thomas L. <tgu...@ya...>]

I am a programmer for a company with a large code base
that runs Doxygen on it for documentation. Because of
our Control Versioning using Visual Sourcesafe, a file
is shared into many directories. When Doxygen
encounters the same file twice, it duplicates all the
function/variable declarations. Is there any way I can
tell it to ignore duplicate function/variable
declarations?

Thanks in advance.

=====
When he was six he believed that the moon overhead followed him, by nine he had deciphered the illusion trading magic for fact. No tradebacks. So this is what it's like to be an adult. If he only knew now what he knew then...- Pearl Jam

__________________________________________________
Do You Yahoo!?
Send FREE video emails in Yahoo! Mail!
http://promo.yahoo.com/videomail/

[Doxygen-users] PL/SQL

[Boulenouar K. <bou...@sy...>]

Hi,
I'm new with Doxygen and i want to generate documentation for a PL/SQL
package.
Is it possible to tweak doxygen configuration to achieve this or are there
some special commands to use ?

Regards,

KHELIFA Boulenouar
Syster Soft
www.6ter.fr

[Doxygen-users] Creating an output generator

[Marc B. <be...@ro...>]

I would like to create a new output generator, derived from outputgen. The
derived part is simple enough, but I do not know what other changes are
needed to wire the new output generator into doxygen. For example, how do
you make the new output generator configurable through doxyfile? I do not
need detailed instructions, but an outline of the classes that need
modifying and a brief description of how they need to be modified would be
helpful and much appreciated. If this information has already been assembled
somewhere, just point me to it. Otherwise, could someone help me out?

Cheers,

Marc Betz

[Doxygen-users] Application Doc

[Scot W. <sc...@wi...>]

Doxygen seems oriented toward documenting a library or API.  I'm finding 
awkwardness in trying to use it for an application.

The main program creates a `man` page with .c in the name.  That's not 
customary for an application program.  The headers for the .c file also include 
that suffix.  I don't see a way to separate the documentation of the source 
code from the application usage documentation.

I also want to document which programs are in a package and how they are to be 
used together.  I created a file only for a document, had it create a Group, 
included information about the various programs, and had each program @ingroup 
themselves and insert some additional info at the bottom of the Group.  This 
info did show up as a Module -- I did have to add the doc file to Doxyfile 
(there is no .dox suffix recognition) early in the list or the Group was not 
defined.  But the Files page shows this doc-only file, and looking at the 
source code shows only one blank line (I start the file with a Doxy comment).

[Doxygen-users] list module(s) that a class belongs to in docs

[Oliver S. <oli...@ut...>]

Hello,

Can doxygen include in a class's documentation which module the class
belongs to?

Currently if I go to a group's page I can see which classes belong to
the group (ie the classes in the module/package), but if I go to a class
I don't know which group it belongs to.  Hence I can't find which other
classes are in the same group without going through all groups until I
find the group that contains it.  Given that classes have the \ingroup
to say which group they belong to, it seems like it would be easy for
doxygen to generate that information.  Yet, find this using scripts is a
major hassle.

Thanks in advance,
Oliver

[Doxygen-users] Doxygen-1.2.13-20020122 in CVS

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

Hi,

I just committed an update to the CVS repository. Since I spend quite some
time on restructuring the XML output, there are still a number of patches 
in the pipeline, so for those who sent me something, there is no need 
to resend (yet). Anyway, here is the changelog for this release:
------------------------------------------------------------------------------
+ CHG: Split up the XML output into an index (index.xml) and one page per
       compound. This allows for faster processing and less memory consumption,
       when using DOM style parsers.
+ CHG: Include files are now only shown in the class documentation if
       and only if SHOW_INCLUDE_FILES is YES.
+ CHG: Doxygen-style C comments inside macro definitions are now preserved
       in the output. Example:
         #define INIT(x) /*! Initializes x. */ void Init() { x = 0; }
+ CHG: When deriving from pure virtual members or IDL interfaces, doxygen will
       now put an "implements/implemented in" list in the documentation instead
       of "reimplements/reimplemented by".
+ ADD: Added a very simple metrics utility
       (see addon/doxmlparser/examples/metrics) which can compute some
       figures based on the XML output generated by doxygen.
+ ADD: Added autodetection for Darwin (MacOSX) to the configure script.
+ ADD: Added option EXCLUDE_SYMLINKS.
       The EXCLUDE_SYMLINKS tag can be used to select whether or not files or
       directories that are symbolic links (a Unix filesystem feature) are
       excluded.
+ ADD: Added option EXTERNAL_GROUPS.
       If the EXTERNAL_GROUPS tag is set to YES all external groups
       will be listed in the modules index. If set to NO, only the
       current project's groups will be listed. (thanks to Darren Oldag
       for the patch).
+ ADD: Included update for Chinese (thanks to Wei Liu).
+ ADD: Included update for translator.pl (thanks to Petr Prikryl)
+ ADD: Updated .spec file (thanks to Emilio Riva).
+ ADD: Included patch by Jochen Hanff to make the index headings configurable
       via style-sheets.
+ BUG: The start of a comment (/*) embedded in a page or example block
       caused parse problems.
+ BUG: operator%= member caused latex error when in pdf hyperlink mode.
+ BUG: fixed parse problem for function typedefs like "typedef int f()"
+ BUG: Qt slots weren't included in the reference/referenced by relations
       (thanks to Gordon Machel for the patch).
+ BUG: Fixed parse problem that occurred when the <SUP> tag was used in
       a brief description.
+ BUG: Private members sometimes showed up in the all member list even though
       EXTRACT_PRIVATE was NO.
------------------------------------------------------------------------------
Enjoy, 
  Dimitri

[Doxygen-users] Bug report, inheritance problem and wishes

[<arj...@wi...>]

> Hi all
> 
> With my Update from version 1.2.10 to 1.2.13.1 (Windows and Linux) I've
> now inheritance problems
> 
> With the following code (taken from CommonC++ Lib)
> 
> class TCPStream : public Socket, public std::streambuf, public
> std::iostream
> {
>   ....
> }
> 
> Doxygen doesn't show in the dependency graph the streambuf and the
> iostream class, the reason seams to be that they are not in the same
> library. 
> 
> The dependency of the following class is correct presented, both classes
> are in the same lib.
> 
> class UDPDuplex : public UDPTransmit, public UDPReceive
> {
>   ...
> }
> 
> I haven't found a new switch or something, so could this be a bug ?
> 
> With the Option INLINE_SOURCES=YES it is possible to include the body of a
> function, but if the Option SEARCH_INCLUDES=YES  is set the included body
> disappear. This happens also with the version 1.2.10. 
> Is this a bug ?
> 
> With the external references it is possible to include links to other
> lib's but it seams only in the function calls. Is it possible to inlude
> this also to the dependency graph and the file-inclusion ?
> 
> Kind regards 
>    arjan

[Doxygen-users] Bug report, inheritance problem and wishes

[<arj...@wi...>]

Hi all

With my Update from version 1.2.10 to 1.2.13.1 (Windows and Linux) I've now
inheritance problems

With the following code (taken from CommonC++ Lib)

class TCPStream : public Socket, public std::streambuf, public std::iostream
{
  ....
}

Doxygen doesn't show in the dependency graph the streambuf and the iostream
class, the reason seams to be that they are not in the same library. 

The dependency of the following class is correct presented, both classes are
in the same lib.

class UDPDuplex : public UDPTransmit, public UDPReceive
{
  ...
}

I haven't found a new switch or something, so could this be a bug ?

With the Option INLINE_SOURCES=YES it is possible to include the body of a
function, but if the Option SEARCH_INCLUDES=YES  is set the included body
disappear. This happens also with the version 1.2.10. 
Is this a bug ?

With the external references it is possible to include links to other lib's
but it seams only in the function calls. Is it possible to inlude this also
to the dependency graph and the file-inclusion ?

Kind regards 
   arjan

[Doxygen-users] ref to a group

[B. <rau...@wa...>]

Hello
I cant reference a gruop. Someone can tell me how do it?

I have tried @ref x but donest work

/** @name x
*/
//@{
#define a 1
#define a 2
//@}


--=20
~~~~ Hasta otra ~~~~
~~ Ra=FAl Benavente ~~
~~~~~~~~~~~~~~~~~~~~

[Doxygen-users] OT: Wrong Mail, Begging Your Pardon

[Thomas R. <re...@di...>]

Hello all,

during the testing phase of the software I'm currently developing, 
I accidentaly send  one of the messages to this list
(I should relly learn about new features in mail-clients I use...., e.g.
mailing-list support)

begging your pardon for that one,

sincerly,
Tom
-- 
Thomas Regner
--------------------
dievision medienberatung
re...@di...

[Doxygen-users] 2 problems with grouping

[Hofi <ho...@fw...>]

Hi All!

    I tried to use grouping with DISTRIBUTE_GROUP_DOC   = YES config
setting. (HTML output, DoxyGen ver 1.2.13.1)

Problem 1.
    I was able to group #defines but no typedefs. :( How can i do it??
Problem 2.
    The grouped #defines got the correct same documentation line, but the
defines disappeared from Defines section, they replaced into 'Detailed
description'. Is there any option to get displayed them on both places?

TIA
    By(t)e
        Hofi

[Doxygen-users] \brief bug

[Scot W. <sc...@wi...>]

I was trying to use \brief to create a description which was terminated by a 
command.  The documentation says it "ends when a blank line or another 
sectioning command is encountered."

The \par and \sa commands are within the "Section Indicators" command group.  
Those two commands do not terminate \brief.  I did not try \section to see if 
that is the definition of "sectioning command".

# /** \file   testerscript.sh \brief Tester Script \sa testershow.sh Perform 
the desired script for tester. */

Note the leading "#", as this is within a shell script file which uses # to 
delimit comments (this issue dealt with in recent message).

I was trying to make a one-line \file entry so as to not get "#" symbols within 
my descriptions.  The goal of the above was to try to get "Tester Script" as 
the Brief Description, with the Detailed Description having a "See also 
testershow.sh" and "Perform desired script for tester."

I also tried:

# /** \file   testerscript.sh \brief Tester Script \par "" Perform the desired 
script for tester. */


This was an attempt to get a Brief Description of "Tester Script" and a 
Detailed Description of "Perform the desired script for tester."  Nope, the new 
paragraph (with an odd Title) was part of the Brief Description.

Re: [Doxygen-users] once again about BCB modifier keyword extensions

[Hofi <ho...@fw...>]

Thanks to all of you boys,

Meanwhile I figured out a solution similar to the DOXYGEN_SHOULD_SKIP_THIS
tip mentioned in the documentation.
Thanks for your reply once again.

Bye
    Hofi

[Doxygen-users] Re: Dox with nonstandard comments

[Scot W. <sc...@wi...>]

> I'm trying to document all the files in my test project.
> Documenting the shell scripts and awk files is awkward.  Those files
> require a comment be marked with "#".

It has been pointed out to me that the INPUT_FILTER Configuration option can be 
used to alter the comment indicators of input files.  So if a file is 
recognized as a shell script a leading "#**" can be replaced with "/**".

The only mention of INPUT_FILTER is in the Configuration section, and the 
description of the following FILTER_SOURCE_FILES can be interpreted as meaning 
that FILTER_SOURCE_FILES=NO willdisable INPUT_FILTER.

Apparently if INPUT_FILTER is defined then all files are run through the 
filter, except FILTER_SOURCE_FILES controls the INPUT_FILTER use when source 
file pages are being created.

Suggested change in "Configuration" page:

INPUT_FILTER 
The INPUT_FILTER tag can be used to specify a program that doxygen should 
invoke to filter for each input file. Doxygen will invoke the filter program by 
executing (via popen()) the command:  
<filter> <input-file>
where <filter> is the value of the INPUT_FILTER tag, and <input-file> is the 
name of an input file. Doxygen will then use the output that the filter program 
writes to standard output. 
+ The FILTER_SOURCE_FILES tag controls whether INPUT_FILTER is also used 
+ when producing source files.

Suggested change to "Documenting the code" page:

+ If using files with different comment markers, the INPUT_FILTER
+ configuration tag can be used to preprocess input files to alter them 
+ for Doxygen use.  Filter programs are not included in the Doxygen 
+ distribution.

Doxygen only allows one brief and one detailed description...

[Doxygen-users] Dox with nonstandard comments

[Scot W. <sc...@wi...>]

I'm trying to document all the files in my test project.

The C source was OK, although Doxygen insists on putting the man page in 
tester.c.1 rather than tester.1

Documenting the shell scripts and awk files is awkward.  Those files require a 
comment be marked with "#".

I first tried to have a separate file with the \file entries for the files 
which I wanted to document, but Doxygen complained that the filenames did not 
match the file's name.

I was able to use
    # /** \file tester.awk
    #     \brief This is the awk script for converting tester.1 output. */

But I can't insert a detailed description without having # embedded within.  
Notice that I terminated the \brief with a comment at the end of the line so 
the following "#" was not seen by Doxygen, but a Detailed Description must 
follow a brief description.  I don't see a \detail command.

I am able to persuade these files to link between each other:
    # /** \addtogroup Scripts Scripts which support tester program
    #     \sa   testerall.ksh
    #     \sa   tester.c */

But again some # are scattered about -- fortunately when they're at the 
beginning of a line they're not too intrusive.

I know I can merge several adjoining \brief entries, but I don't see ways to 
deal with other problems with # symbols scattered about.  Can I nest /** # **/ 
or use a remark to have the text until the next Doxygen command be ignored?  (I 
see \ignore, \rem, \comment all have meanings already -- maybe "\**")

And for the future reader trying to do this... I was able to have the rest of 
the file not be inserted in docs by Doxygen except when the source was looked 
at by ending my comments in the header with:
    #  /** \verbatim */
and letting that expire at the end of the file.

[Doxygen-users] Newsletter-Template

[Thomas R. <re...@di...>]

Hallo @anrede; @name;,

aktuell sind folgende Stellenangebote online verfügbar:

@forEachJob;
	@jobBezeichnung;
	@jobEinstelldatum;
	@jobUrl;

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

@endForEach;


wir hoffen, dass etwas für sie dabei ist, blah!

Wenn sie diesen Newsletter nicht mehr Beziehen wolen, klicken Sie bitte hier:

@unsubUrl;

Re: [Doxygen-users] once again about BCB modifier keyword extensi ons

[Aaron B. <Aa...@co...>]

Hi,

__declspec() is not only a borland extension. MS MFC and ATL libs also =
use
this stuff. You can work around this problem with help of the =
PREDEFINED tag
in a configuration file. In my configuration file I have the =
MACRO_EXPANSION
tag set to yes and a long list for PREDEFINED. You can handle =
__declspec
like a macro. Try something like this:

PREDEFINED =3D "__declspec(mod)=3Dwhatever you want to have in your
documentation"

I don=B4t expand __declspec() so my entry for this is:

PREDEFINED =3D "__declspec(mod)=3D "

With that, the __declspec() will be ignored by doxygen (to be correct, =
it
will be replaced with an empty string I think). If you want to =
interpret it,
mod contains your modifier (for example dllexport). I think this should
work.=20
Take a look on the Preprocessing section of the doxygen documentation, =
there
it is described with some examples.

hope this helps,

Aaron

Message: 6
Date: Fri, 18 Jan 2002 15:26:56 +0100
From: Hofi <ho...@fw...>
To: Doxygen users list <Dox...@li...>
Subject: [Doxygen-users] once again about BCB modifier keyword =
extensions

Hi All,

    Last time i wrote about problems with  __declspec(dllimport) and
namespaces.

I found that all modifiers like __declspec(<decl-modifier>)
where decl-modifier could be
 dllexport
 dllimport
 naked
 noreturn
 nothrow
 novtable
 property
 selectany
 thread
 uuid

could confuse doxygen :((
classes with __declspec() are all ignored,
variables like
//< Initialization of the default global instance of a logger list.
HLoggers __declspec(dllexport) loggers;
are miss interpretered.
e.g.
      const char HLib::__declspec  (  dllimport     )  [inline]


i think the reason doxygen works this way is because __declspec is a =
borland
language extension only :((
so i only can hope that doxygen could interpret these modifiers in the
future, it would be a nice thing from Dimitri.

Thanks
    and sorry for my terrible english.
        bye
            Hofi

RE: [Doxygen-users] once again about BCB modifier keyword extensi ons

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

Hi Hofi,

You can probably solve your probem by proper setting of
PREDEFINED configuration option.  See doxygen documentation
(doxygen\html\preprocessing.html see the end of the document).
You can even find example there and it contains also 
___declspec(a) converted to nothing.
If you need to produce something else (instead of nothing), try
to modify the PREDEFINED.

Petr

> -----Original Message-----
> From:	Hofi [SMTP:ho...@fw...]
> Sent:	Friday, January 18, 2002 3:27 PM
> To:	Doxygen users list
> Subject:	[Doxygen-users] once again about BCB modifier keyword
> extensions
> 
> Hi All,
> 
>     Last time i wrote about problems with  __declspec(dllimport) and
> namespaces.
> 
> I found that all modifiers like __declspec(<decl-modifier>)
> where decl-modifier could be
>  dllexport
>  dllimport
>  naked
>  noreturn
>  nothrow
>  novtable
>  property
>  selectany
>  thread
>  uuid
> 
> could confuse doxygen :((
> classes with __declspec() are all ignored,
> variables like
> //< Initialization of the default global instance of a logger list.
> HLoggers __declspec(dllexport) loggers;
> are miss interpretered.
> e.g.
>       const char HLib::__declspec  (  dllimport     )  [inline]
> 
> 
> i think the reason doxygen works this way is because __declspec is a
> borland
> language extension only :((
> so i only can hope that doxygen could interpret these modifiers in the
> future, it would be a nice thing from Dimitri.
> 
> Thanks
>     and sorry for my terrible english.
>         bye
>             Hofi
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> Doxygen-users mailing list
> Dox...@li...
> https://lists.sourceforge.net/lists/listinfo/doxygen-users

[Doxygen-users] C Brief Compound Members?

[Scot W. <sc...@wi...>]

It would be nice to use brief compound members in C programs, but there is no 
in-member brief format starting with the C comment indicator "/*" which fits on 
one line.  The /**< creates a "Detailed" description even for one-liners.

#define   LOCAL_BUFFER_SIZE 4096 /**< HTML has link to one-line detail */
int myfunction(
    char *password,        /**< This is a detailed description */
    char *errormessage     /**< One-liner looks odd in docs. */
) ( ... }

I haven't examined the parser.  Maybe it could handle /**<< for a Brief 
Description?

Re: [Doxygen-users] Forward declaration of enums

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

A bit of off-topic C++ arcana...

Quoting br...@sh...:

> In general, you don't want to forward-declare enums. I'm not sure off the
top 
> of my head whether the syntax is even valid; even if it is, you shouldn't
use 
> it. C++ allows the size of an enumerant to depend on the range of values
the 
> enumeration must be able to hold. To derive this information, the compiler
must 
> be able to see the definition of the enumeration in each translation unit
where 
> the enumeration is used.

This is a little misleading. Forward declarations never tell the compiler
the size of something; that's true for forward class, struct, and enum
declarations. They're only useful where you need to mention something by
name but don't want to include the full declaration, for instance if you
need to specify pointer or reference arguments. This technique is very
useful for decoupling header files, keeping build dependencies to a minimum.
So forward enum declarations are potentially just as useful in this regard
as forward class and struct declarations.

Where an enum value, variable, or parameter is used, of course, the compiler
does need to see the full declaration.

[Doxygen-users] once again about BCB modifier keyword extensions

[Hofi <ho...@fw...>]

Hi All,

    Last time i wrote about problems with  __declspec(dllimport) and
namespaces.

I found that all modifiers like __declspec(<decl-modifier>)
where decl-modifier could be
 dllexport
 dllimport
 naked
 noreturn
 nothrow
 novtable
 property
 selectany
 thread
 uuid

could confuse doxygen :((
classes with __declspec() are all ignored,
variables like
//< Initialization of the default global instance of a logger list.
HLoggers __declspec(dllexport) loggers;
are miss interpretered.
e.g.
      const char HLib::__declspec  (  dllimport     )  [inline]


i think the reason doxygen works this way is because __declspec is a borland
language extension only :((
so i only can hope that doxygen could interpret these modifiers in the
future, it would be a nice thing from Dimitri.

Thanks
    and sorry for my terrible english.
        bye
            Hofi