doxygen-users

[Doxygen-users] Issue with __attribute__ of gcc

[Hariharan <ha...@gm...>]

Hi All,=20
         We are trying to document our code based on doxgen scheme, most =
of our data strucutures follow strict alignment restriction and hence we =
have used __attrubute__((aligned(16))) before structure names. This =
confuses doxygen and it thinks that the structure name is actually =
__attribute__, also we have structures and unions inside a strucuture =
that are not perticularly named, how does doxygen take care of such =
senarios?

     I saw a patch being submitted in dev list , tried that but it does =
not seem to be of much help.=20

Any suggestions as to how we could get doxygen to make this work ?


Thanks
-Hariharan

Re: [Doxygen-users] Issue with __attribute__ of gcc

[Emil M. <mx...@se...>]

At least you can try to use macro expansion for __attribute__(something) 
- and then not expand that macro during doxygen processing.

Anyway, if you try to write portable code, you should not have in-place 
compiler extensions, which __attribute__ surely is (that means, very few 
C/C++ compilers other than gcc will support that keyword). I've solved 
this stuff using e.g.:


#ifdef __GNUC__

// Define how to declare functions/methods with printf(3) like semantics.
#define PRINTFLIKE( format_index, arguments_index ) \
     __attribute__(( format( printf, (format_index), (arguments_index) ) ))

#else

// Defined as empty macro for all other compilers, and also for doxygen.
#define PRINTFLIKE( format_index, arguments_index )

#endif // __GNUC__


and then I use e.g.

PRINTFLIKE(1,2) char* MyPrintF( const char * const sFormat, ... );



Hariharan wrote:

> Hi All,
>          We are trying to document our code based on doxgen scheme, most 
> of our data strucutures follow strict alignment restriction and hence we 
> have used __attrubute__((aligned(16))) before structure names. This 
> confuses doxygen and it thinks that the structure name is actually 
> __attribute__, also we have structures and unions inside a strucuture 
> that are not perticularly named, how does doxygen take care of such 
> senarios?
>  
>      I saw a patch being submitted in dev list , tried that but it does 
> not seem to be of much help.
>  
> Any suggestions as to how we could get doxygen to make this work ?
>  
>  
> Thanks
> -Hariharan

Re: [Doxygen-users] Issue with __attribute__ of gcc

[Dave D. <do...@do...>]

On Mon, May 22, 2006 at 09:49:31AM +0200, Emil Maskovsky wrote:
> 
> At least you can try to use macro expansion for __attribute__(something) 
> - and then not expand that macro during doxygen processing.
[...]
> PRINTFLIKE(1,2) char* MyPrintF( const char * const sFormat, ... );

Seconding this technique.  Note that if you have EXPAND_ONLY_PREDEF
set to YES then you'll need to put the no-op versions of the macros
into the PREDEFINED list:

  PREDEFINED = \
    "PRINTFLIKE(x,y)="

> Anyway, if you try to write portable code, you should not have in-place 
> compiler extensions, which __attribute__ surely is (that means, very few 
> C/C++ compilers other than gcc will support that keyword).

Most attributes are just compiler hints and can safely be dropped
without breaking things.  For example I normally compile with warnings
cranked way up and there are some functions that (for API reasons)
have unused arguments.  I use a macro to apply the "unused" attribute
so that gcc doesn't issue a warning about them.

Things like packing and alignment attributes are trickier, because the
program could potentially malfunction without them.  For example the
data might be used with some assembly code that requires more precise
alignment than the C ABI can normally guarantee.  In these cases I'd
still use a macro, but have the code issue an #error if the compiler
can't support the extension.

                                                  -Dave Dodge