Re: Best Practices: #include

Tech-Archive recommends: Fix windows errors by optimizing your registry

From: Balboos (balboos_at_masonicbrother.com.No.Spam)
Date: 05/19/04 

Date: Wed, 19 May 2004 14:54:34 GMT

That's what I was getting at. Some things are essential, and including
them should not be left to chance (and figuring out exactly what header
is that's missing).

Balboos

Keith Sheppard wrote:

>>>I don't understand what you mean by essential headers. Could you give
>>>some examples of essential and non essential headers, or otherwise explain
>>>the difference?
>
>
> I'm not sure whether this is what "Balboos" had in mind, but consider:
>
> Fred.h:
> class Fred
> {
> public:
> Fred();
> void SomeMethod();
> }
>
> Jim.h:
> class Jim
> {
> public:
> Jim();
> void JimsMethod(class Fred aParameter);
> };
>
> You really ought to #include "Fred.h" in Jim.h because any attempt to
> include Jim.h without Fred.h will result in a compilation error because
> class Fred will be undefined.
>
> Change Jim.h to this:
> class Jim
> {
> public:
> Jim();
> void JimsMethod(class Fred *pParameter);
> };
>
> Now it's less clear. The compiler is happy to entertain the idea of a
> pointer to an as yet undefined class because all pointers are the same size.
> If a module never needs to call JimsMethod, and has no other need for class
> Fred, it can include Jim.h without Fred.h and get no compilation error. In
> this case, my personal preference would be to not have a #include "Fred.h"
> in Jim.h. If you do, you are forcing every module with a dependency on
> class Jim to be recompiled whenever class Fred changes, even those modules
> which have no interest in class Jim.
>
> However, as I said, that's just my personal preference. Other folk do it
> elsewise.
>
> Keith
>
>