[prog] [C/C++] what to put in header files.

Hemingway, Neil neil.hemingway at barclays.co.uk
Fri Sep 20 13:14:13 EST 2002


Hello,

	I've read this thread with interest because I've been bitten by this
in the past, and I wanted to pass on my experience...

For small scale projects what has been said is accurate, but as projects
get larger, what comes to dominate the build time is header inclusion.
To mitigate this you should only include header files when you absolutely
must, and most people are surprised when they find out the cases when you
do _not_ have to include the header file.

For C++, it boils down to whether the compiler needs to see the class
definition, or whether it simply needs to know that a class with such
a name exists somewhere.  For example, if a .cpp file refers to a attribute
of a class, then the compiler needs to know not only the address of the
class,
but also the offset into the class for the attribute.  In order to do this,
it
must have the class definition, and therefore you need to include the
header file.

On the other hand, if there is a class named Foo, and another class (Bar)
has a member attribute of type pointer to Foo, then the compiler does _not_
need to see the definition of class Bar to compile Foo.  Consequently, you
do
not need to include the header, you can simply say within the file defining
Foo:

	class Bar;

and this will satisfy the compiler.

The book I refer to below has all the details, and lists all of the
situations
where you do and where you do not need to include the header file.  I only
don't
include them here because I can't remember them all.

Suffice it to say that by taking this approach, you can dramatically cut the
compilation time for a large project.

Reference: "Large Scale C++ Design" by John Lakos published by Addison
           Wesley (ISBN: 0201633620)

Regards, Neil

-----Original Message-----
From: Kathryn Hogg [mailto:kjh at flyballdogs.com]
Sent: 19 September 2002 15:26
To: programming
Subject: Re: [prog] [C/C++] what to put in header files.



> One rule that really helps with compiling huge projects is that each
> include file should include as few other files as possible.  If class
> Foo uses class Bar, it's much better to include Bar.h in Foo.cpp rather
> than in Foo.h.

May I add something to this advice?  If Foo.h uses anything from class Bar,
then Foo.h should include Bar.h.  Not only does this make it easier users of
class Foo since they only need to include Foo.h but it may be required for
C++ template instantiation on some systems.  Of course, I always guard
multiple inclusion of dependent header files within files.

 > Those things you often see at the beginning and end of an include file:
>
> #ifndef FOO_H
> #define FOO_H
> [ ... body of file ... ]
> #endif /* FOO_H */

I always use some sort of organization tag like CES_FOO_H since I may use
code developed elsewhere that uses FOO_H.

-- 
Kathryn


_______________________________________________
Programming mailing list
Programming at linuxchix.org
http://www.linuxchix.org/mailman/listinfo/programming


**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************


Internet communications are not secure and therefore the Barclays Group
does not accept legal responsibility for the contents of this message.
Although the Barclays Group operates anti-virus programmes, it does not
accept responsibility for any damage whatsoever that is caused by
viruses being passed.  Any views or opinions presented are solely those
of the author and do not necessarily represent those of the Barclays
Group.  Replies to this email may be monitored by the Barclays Group
for operational or business reasons.




More information about the Programming mailing list