«

When I declare a function prototype in a header-file, have
I to include this header-file in the implemenation file?
Example:
//main
#include "myfunction.h"
int main()
{
myFunction();
return 0;
}

//myfunction.h
void myFunction();

//myfunction.cpp
#include "myfunction.h" // I am concernd about this include-statement

void myFunction()
{

Roman Töngi wrote:

> When I declare a function prototype in a header-file, have
> I to include this header-file in the implemenation file?
> Example:

> > cat main.cpp
> #include "myfunction.h"
> int main(int argc, char* argv[]) {
> myFunction();
> return 0;
> }
>
> > cat myfunction.h
#ifndef GUARD_MYFUNCTION_H
#define GUARD_MYFUNCTION_H 1

> void myFunction(void);

#endif//GUARD_MYFUNCTION_H
>
> > cat myfunction.cpp
> #include "myfunction.h" // I am concerned about this include-statement

Strongly recommended!

> void myFunction(void) {
> // ...
> }
>
>
> The code is compiled
> whether myfunction.h in myfunction.cpp is included or not.
> But is it good programming style if you do so?

You should *always* include the [module] interface (header file)
int the [module] implementation file
so that the compiler can check for any inconsistency.

Roman Töngi wrote:
> When I declare a function prototype in a header-file, have
> I to include this header-file in the implemenation file?
> Example:
> //main
> #include "myfunction.h"
> int main()
> {
> myFunction();
> return 0;
> }
>
> //myfunction.h
> void myFunction();
>
> //myfunction.cpp
> #include "myfunction.h" // I am concernd about this include-statement
>
> void myFunction()
> {
> .
> .
> }
>
>
> The code is compiled whether myfunction.h in myfunction.cpp is included
> or not. But is it good programming style if you do so?
>
> Thanks in advance
> Roman
>
>

I always include it. That way if you have accidently
implemented a function differently than the prototype
listed in the header file, the compiler will tell you when
the .cpp is compiled.

Most header files contain more than a single prototype,
and most .cpp files contain more than a single function.
It's often a good idea to group things by their function
(e.g. all matrix stuff in matrix.h and matrix.cpp).

'defines' are often used in a header to ensure that its
content will be evaluated only once - no matter how many
source files or other header files 'include' it, eg:

in stuff.h:

#ifndef STUFF_H
#define STUFF_H

the actual content of stuff.h goes here

#endif

Larry

--
Anti-spam address, change each 'X' to '.' to reply directly.

Roman Tongi wrote:
> When I declare a function prototype in a header-file, have
> I to include this header-file in the implemenation file?
> Example:
> //main
> #include "myfunction.h"
> int main()
> {
> myFunction();
> return 0;
> }
>
> //myfunction.h
> void myFunction();
>
> //myfunction.cpp
> #include "myfunction.h" // I am concernd about this
> include-statement
> void myFunction()
> {
> .
> .
> }
>
>
> The code is compiled whether myfunction.h in myfunction.cpp is
> included or not. But is it good programming style if you do so?

There is no need (as you have discovered) for 'myFunction' to be
declared twice when you compile 'myfunction.cpp'. However, including
the header into the same compilation unit is often done because there
are other things declared/defined there that all units that include
that header need. The most common information is the class definition
that is needed for the users of the class and for the implementation
of the member functions.

V

E. Robert Tisdale wrote:
> [...]
> You should *always* include the [module] interface (header file)
> int the [module] implementation file
> so that the compiler can check for any inconsistency.


What inconsistency will the compiler be able to recognize in
a situation like this

#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.

V

Victor Bazarov wrote:

> E. Robert Tisdale wrote:
>
>>[...]
>>You should *always* include the [module] interface (header file)
>>int the [module] implementation file
>>so that the compiler can check for any inconsistency.
>
> What inconsistency will the compiler be able to recognize
> in a situation like this
>
> #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.

So what's your point?
Certainly, it would be nice if your compiler could read your mind
but I can't.

> #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

It is a good programming style. A few more rules are needed
to efficiently manage header files.

Refer to the following article for details:
http://www.eventhelix.com/RealtimeMa...dePatterns.htm

Deepa
--
EventStudio 2.5 - http://www.EventHelix.com/EventStudio
Generate Sequence diagrams from a simple declarative language