Recall how the whole compile-link process works.

Each .cpp file is compiled individually into .obj files which basically contain machine language code that doesn't have all the external addressing(calls to functions in other .cpp files or libraries, etc..) resolved.

Then all the .obj files are linked which resolves all the addressing and the final .exe is created.

If you call a function that is defined in a different .cpp file without providing a function prototype, the compiler gets pissy because it doesn't know anything at compile time about the function you're calling. That's what all the function prototypes, type definintions, etc. really are, just ways to tell the compiler to quit bitching and that everything will be taken care of at link time. So that's the stuff you put in the .h files. This is an oversimplification, but I hope you get the general idea.


Edited by - B-Barlow on January 2, 2002 6:45:47 PM

I want to add this, because I think the question about including
implementation files, refers to my point of integrating the class / class set or function / function set into other projects.

You have to include the header file ( often .h ) and LINK with the object file ( often .obj ) compiled from the implementation file ( often .cpp or .c in C/C++ progs ).

Or if you want to customize the implementation for your current project and want to have it in your project workspace, you could add the implementaion file to your project ( if you''ve an IDE that supports projects ). Then most IDEs automate the thing and you don''t have to say explicitly to link with that object file.
Also they usually compile the implementation files when you build your project and they aren''t compiled yet.

The rest of the question is explained pretty good, I think, by B_Barlow ( sorry if the name isn''t spelled correct ).

quote: Original post by Myopic Rhino
Lots of reasons. One of the best is that putting everything in the header means that everything will have to be recompiled whenever you make a change.

Not entirely true. There is a compiler switch in VC++ that tells the compiler to compile the header files only once, unless a change has been made to one of them. This means that after the first compile, subsequent compiles are much quicker.

However this certainly does justify sticking it all in a header, I''m just pointing out (for general purpose) that you can precompile like that.



_________________________________________________________________

Drew Sikora
A.K.A. Gaiiden

ICQ #: 70449988
AOLIM: DarkPylat

Blade Edge Software
Staff Member, GDNet
Public Relations, Game Institute

3-time Contributing author, Game Design Methods , Charles River Media (coming GDC 2002)
Online column - Design Corner at Pixelate

NJ IGDA Chapter - NJ developers unite!! [Chapter Home | Chapter Forum]

quote: Original post by Gaiiden
Not entirely true. There is a compiler switch in VC++ that tells the compiler to compile the header files only once, unless a change has been made to one of them. This means that after the first compile, subsequent compiles are much quicker.

Funny. When I wrote that, I thought that someone might bring precompiled headers up, but chose not to mention them because (1) doing so would unnecessarily complicate the explanation, (2) the fact that you can use them doesn''t justify putting everything in the header anyway, and (3) I was speaking in a broader sense - not every compiler supports precompiled headers.

I know, I just felt that should be known for general optomization during multiple source code compiles where you don''t touch the headers. And I did point out that I wasn''t using it as a justification. Tho you make a good point that it''s not a general thing. Oh well.