#ifndef BLAH // This part
#define BLAH // is included
// from a header
int foo(int); // file when
// we use the
#endif // #include
int foo(double a)
{
return 42;
}
? There is no connection between the 'foo' declared above and
'foo' defined in the translation unit.
Actually, that was a magnificient practice in the bad old C days, where you
had no overloading, and where the compiler could supply a(n) (usually wrong)
function declaration if you missed to supply it.
In C++ you are usually writing classes, and then you must supply the class
declaration to the translation unit where you define its methods. So you
must #include the header.
Even if you have only the functions, their arguments may need certain types
to be declared prior to declaring the functions. So by including first your
header in your translation unit before you include other headers (needed
only for the implementation), you check whether your header itself #includes
all its dependencies. If you don't do that, you might force your clients to
#include headers in a particular order, which is a maintenance problem.
If you don't have even this problem, you might have it in the very next
redesign of your code, so why not #include the header now and not worry
later.
And if you are absolutely sure that this will never happen, IMHO you have a
very rare case and you should not violate a good rule just for it.
So I think that to #include the header into the implementation is a Good
Thing. I guess that Victor would agree, and my point is just to make sure
that the OP understands the true reasons for it (instead of arguing about
false reasons). I don't claim I quoted all good reasons for this practice -
if someone knows more, please have your word.
Rade