doxygen-users

RE: [Doxygen-users] (no subject)

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

>
> Here is one solution, all the following is in the
> header file -
>
> ------------------------------
> class A
> {
> public:
>   int method1 ();
>   void method2 ();
> };
>
> /**
>  * Blah
>  * @return blah
> */
> int A::method1 () const {return simple_thing;}
>
> /**
>  * Blah2
>  */
> void A::method2 () {do_something_simple ();}
> --------------------------------
>
> But I have a question about inlining - will some
> compilers fail to inline methods because the
> definition is now separate from the declaration?

You HAVE to say
class A
{
 public:
   int method1 ();
   void method2 ();
};

Otherwise the compiler won't know you want to inline, and it will generate a
A::method1 implementation in every object file whose source happens to
include your header (think about what #include does and it will make sense).
This will give you lots of linking problems.

Aside from that, personally, I prefer my documentation in the class
definition, while I put the inline implementations somewhere else. In that
way, people reading the source only have to check the class definition and
nothing else.
(I put the inlines in a spearate file blabla.inl to stress that fact). But
that's up to you of course.

All the best,

Kris Thielemans
Imaging Research Solutions Ltd
Cyclotron Building
Hammersmith Hospital
Du Cane Road
London W12 ONN, United Kingdom

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

RE: [Doxygen-users] (no subject)

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

fantastic. I forgot to put the 'inline' in there..

You HAVE to say
class A
{
 public:
   inline int method1 ();
   inline void method2 ();
};


Sorry

Kris

RE: [Doxygen-users] (no subject)

[Paul B. <pee...@ya...>]

Kris, Victor,

Thanks, but I don't know if I agree with what has been

said.  In the first case (below), I assume we all
agree
that even though I did not explicitly say 'inline',
the compiler might choose to inline a method.

But my second case is very similar - the definitions
are still in the header file, they are simple placed
outside the main class declaration.  So why should the
compiler not choose to inline them anyway?  After all
all the information is still there, in the header
file, 
at compile time.

Now there may be a reason it doesn't do this, which
is what my question is about.  But I cannot see that
my use of the 'inline' keyword is going to
help.  This is just a suggestion, after all, not
binding on the compiler.  Is there a hard rule
somewhere that if the method definition is separate
from the method declaration, but still in the include 
file, it will not be inlined unless 'inline' is used? 

Thanks,
Paul.


----------FIRST CASE-----------------------
class A
{
public:
  int method1 () const {return simple_thing;}
  void method2 () {do_something_simple ();}
};
----------END FIRST CASE-----------------


----------SECOND CASE--------------------
class A
{
public:
  int method1 ();
  void method2 ();
};

/** 
 * Blah
 * @return blah
*/
int A::method1 () const {return simple_thing;}

/**
 * Blah2
 */
void A::method2 () {do_something_simple ();}

---------END SECOND CASE-----------------------



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

RE: [Doxygen-users] (no subject)

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

Hi Paul,
>
> Kris, Victor,
>
> Thanks, but I don't know if I agree with what has been
>
> said.

Maybe you should read a good C++ book then! This is not a doxygen question
by the way, so I don't think we should be discussion this further on this
list (after this email of course!)

> In the first case (below), I assume we all
> agree
> that even though I did not explicitly say 'inline',
> the compiler might choose to inline a method.
>

As far as syntax goes, in the first case you can put inline in there or not,
syntactically it means exactly the same: it's an 'inline' method.

This doesn't say anything at all about what code the compiler will generate
(even with an explicit inline, it doesn't have to inline it).
It does say something about how the compiler should handle linking etc. In
particular, a function/method declared as inline can occur in multiple
object files, while a non-inline (and non-static) one cannot.

> But my second case is very similar - the definitions
> are still in the header file, they are simple placed
> outside the main class declaration.  So why should the
> compiler not choose to inline them anyway?  After all
> all the information is still there, in the header
> file,
> at compile time.
>

You have to remember that the actual compiler actually never sees your
header file, it only sees the preprocessed thing, which has the header files
and your .cpp file merged into 1 huge text file.

> Now there may be a reason it doesn't do this, which
> is what my question is about.  But I cannot see that
> my use of the 'inline' keyword is going to
> help.  This is just a suggestion, after all, not
> binding on the compiler.  Is there a hard rule
> somewhere that if the method definition is separate
> from the method declaration, but still in the include
> file, it will not be inlined unless 'inline' is used?
>

Depends what you mean. Syntactically, the only ways to get it the status of
an inline function are
- put it in the class definition
- add inline to its function declaration

If at some point, the compiler needs to fill in the function call, it can
choose to inline or not, depending on your suggestion and what it thinks is
best. That's independent of the above. (For example, you might have a
non-inline function which you call in the same object file as its
definition. The compiler might choose to inline that function call).

I guess here's the difference. You can have an inline function, or the
compiler can inline a function call. They're largely (but hopefully not
completely) independent of each other.


I hope this clarifies the issue. If not, I'd be willing to discuss this off
the list, although I'm not sure what other words I can use. You might be
better off in alt.languages.C++ or so.

All the best,

Kris

RE: [Doxygen-users] (no subject)

[Wagner, V. <VW...@se...>]

it's not binding when you declare/define the functions inside the class
either.

I don't make the rules.. I just report them

-----Original Message-----
From: Paul Beardsley [mailto:pee...@ya...]
Sent: Wednesday, 2002 January 16 12:09
To: dox...@li...
Subject: RE: [Doxygen-users] (no subject)


Kris, Victor,

Thanks, but I don't know if I agree with what has been

said.  In the first case (below), I assume we all
agree
that even though I did not explicitly say 'inline',
the compiler might choose to inline a method.

But my second case is very similar - the definitions
are still in the header file, they are simple placed
outside the main class declaration.  So why should the
compiler not choose to inline them anyway?  After all
all the information is still there, in the header
file, 
at compile time.

Now there may be a reason it doesn't do this, which
is what my question is about.  But I cannot see that
my use of the 'inline' keyword is going to
help.  This is just a suggestion, after all, not
binding on the compiler.  Is there a hard rule
somewhere that if the method definition is separate
from the method declaration, but still in the include 
file, it will not be inlined unless 'inline' is used? 

Thanks,
Paul.


----------FIRST CASE-----------------------
class A
{
public:
  int method1 () const {return simple_thing;}
  void method2 () {do_something_simple ();}
};
----------END FIRST CASE-----------------


----------SECOND CASE--------------------
class A
{
public:
  int method1 ();
  void method2 ();
};

/** 
 * Blah
 * @return blah
*/
int A::method1 () const {return simple_thing;}

/**
 * Blah2
 */
void A::method2 () {do_something_simple ();}

---------END SECOND CASE-----------------------



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

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

RE: [Doxygen-users] (no subject)

[Catenacci, O. <Ono...@co...>]

Hi Chris,

Interesting question.  Is there some reason you can't make a copy of the
source to a different directory and modify it in the other directory?  

--
Onorio Catenacci
I do not speak for my employer

>  -----Original Message-----
> From: 	Chris Barlas [mailto:chr...@wi...] 
> Sent:	Wednesday, March 19, 2003 4:41 PM
> To:	dox...@li...
> Subject:	[Doxygen-users] (no subject)
> 
> hi,
> 	I am looking to try a few things with doxygen, but I am not able to
> modify the source files.  I have done some documentation outside of the
> files using a separate file and running that into doxygen.  Can you
> document parameters, returns, class members, functions, defines ...
> outside of the source as well in a separate file?  
> Also.. can you rearrange or make certain module grouped together under
> user defined headings or paragraphs?
> 
> ::chris
> 
> 
> 
> 
> 
The contents of this e-mail are intended for the named addressee only. It
contains information that may be confidential. Unless you are the named
addressee or an authorized designee, you may not copy or use it, or disclose
it to anyone else. If you received it in error please notify us immediately
and then destroy it. 

RE: [Doxygen-users] (no subject)

[Irene H. <Ire...@wo...>]

I've now tried both of these suggestions and neither fixed my problems.
=20
There seems to be some sort of multiple comments problem on the #define
statements, hence once a comment has been set for all members of the
group, they cannot have extra individual comments.
=20
Like Roberto I thought that should fix my grouping functions in multiple
header files problem, however it seems to not have. I am puzzled as to
what the problem there is.
=20
Can anyone help?
=20
Thank you
=20
=20

________________________________

From: Roberto Tirabassi [mailto:rti...@3d...]=20
Sent: 09 July 2004 12:21
To: Doxygen Users
Cc: Irene Higson
Subject: Re: [Doxygen-users] (no subject)


At 12.43 09/07/2004, you wrote:


	Hi,
=09
	I am trying to group a set of #define statements, due to a
general
	comment for them. In addition these statements also have
individual
	comments. Does this cause problems?=20
	I am asking because the specific comments appear in the header
for the
	statements in the html documentation, as well as where they are
supposed
	to be, and the general comment does not appear anywhere.
=09
	To clarify:
	/*@{*/
	/**General comment, applies to all following #define
statements*/
	#define xxx /**Specific comment1*/
	#define yyy /**Specific comment2*/
	#define etc. /**Specific commentN*/
	/*@}*/


        Use /**< Specific comment1 */ to assign this comment to the
specified define.



	I am also having problems grouping functions in different header
files.
	I have tried using @defgroup in one and @addtogroup in the other
header
	file, also tried @addtogroup in both, as well as @defgroup in
one and
	@ingroup in the other.
	The only output I get is for the header file in which I have
used
	@defgroup, even if I change this to @addtogroup.
	What should I use to manage?


        I use @defgroup into one file and @ingroup into all functions
and parts to add to that group... but I probably misunderstood what
you're looking for...



                                             Roberto Tirabassi.

=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
Roberto Tirabassi (rti...@3d...)
"I think (I doubt) therefor I am is not a reversible equation"
(Descartes)

3D Informatica, S.Lazzaro di Savena, Bologna, Italy
Phone +39 051 VOICE 450844, FAX 451942
WWW -> http://www.3di.it <http://www.3di.it/> , FTP -> ftp.3di.it
<ftp://ftp.3di.it/> On Line Support -> http://www.3di.it/manuali/
User Support -> https://cesare.3di.it/h3/rh3/a3di_attivita/fSegnalazione

3D Informatica, Roma, Italy
Phone +39 06 8840309
WWW -> http://www.highwaytech.it

<http://www.highwaytech.it/> This mail is virus free due to Norton
Antivirus.
=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=20
________________________________________________________________________
This email has been scanned for all viruses by the MessageLabs Email
Security System.=20
________________________________________________________________________