OK
So I am trying to understand separate compilation and learn how to use 'make' and how to set up Makefiles. The question that I have is regarding a solved example given in a book I am studying from. Here it is:

There are several source files (four). One with the main function, and the rest of them each containing a function used in the main. Now, each of these 'nonmain'
source files HAS ITS OWN HEADER FILE. These header files are then #included in the main source file.
Now, I understand that the book is trying to teach me something, but I am curious if the header files are really necessary (or even usefull) in this case? Can't I just set up a makefile without them, and not mention them in the mainfile?
In what specific case would header files be absolutely essential?

Thanks for your help.

The header file is essential here. If you do not comile all the source togeterh, for example:

>gcc main.c -c
>gcc nonmain1.c -c
>gcc nonmain2.c -c
>gcc main.o nonmain1.o nonmain2.o -o main

the -c option tells the compile to just make object files (*.o), and not to link them yet. so the functions in nonmain1.c are defined there, but called from main.c. if nonmain1.c and main.c are not compiled together, then main.c will not know what to do with the function defined in nonmain1.c. This is where the header file comes in.

The header file for nonmain1.c (probably named nonmain1.h) is just a DECLARATION of the functions DEFINED in nonmain1.c. (remember that if you DEFINE a function after your main() function, you have to DECLARE it before main(), to let the compiler know that it doesn't need to worry about functions that aren't defined yet, because their definition will be coming along later.). This is what the header file is doing, it is allowing main.c to 'see' the functions that are available in nonmain1.c. that way, when the compiler runs into a function it doesn't know and sees that it has been declared in nonmain1.h, it knows it can move on because the definition will be available later.

by keeping the sources separate, you can save on recompiling time. for example, if you had a directory full of source files named from nonmain1.c to nonmain10000.c, if you compiled the executable all at once, you would have to recompile all the .c files every time you made a change to one. by compiling them separately, you can just recompile the files that have been changed.

make is a tool that can go through your source files, figure out which ones have been changed since the last time you compiled, recompile only the sources that have changed, and then recompile the executable.

hope thats not too long, boring and/or confusing.

sorry, i forgot you were using c++. same applies, just replace .c with .cpp and gcc with g++.

or...
sed "s/gcc/g++/g" my_text_above | sed "s/\.c /\.cpp /g"

Brief addendum:

1. Yes, separate header files are a Good Thing. For many reasons.
Feel free to inquire further if you'd like to discuss any of these reasons in greater detail.

2. And yes, if you use headers then you very definitely need to include them in your makefile dependencies.

Few bugs are more insidious - and more difficult to reproduce and track down - than data declarations in a
header falling out of sync with the implementation in the body.

'Hope that helps .. PSM

Thanks guys. OK...I guess my follow up question is just another formulation of my original question:
In case when 'nonmain' source file isn't too big and complex, is it possible to combine it with its header file into one file (nonmain.h) that would contain both declaration and definition?
I am probably wrong, but it just seems like a separate header file for a simple
10 line function is an overkill.

Anybody?

yes, you could do that, and it probably is overkill. but using a 100 line function to demonstrate the point would also be overkill.

OK.

Sirclif,
thanks for a good explanation of the purpose of the header file. It makes more sense now.

frankie_dj - I assume we adequately expressed the following points:

1. You should always use a header file whenever you want to share one or
more declarations between two or more source files.

2. This is vitally true for data definitions (including C++ class definitions);
it's also true (but less urgently so) for function prototypes.

3. You can think of a C/C++ header file as basically an "interface declaration".

4. System headers (like "#include <stdio.h>") use angle brackets.
Local headers (the kind you'd be writing) use double quotes (#include "myheader.h").

5. You set the compiler's search path for include files with the "-I" compiler
switch (equally true for Linux "gcc" as for Windows "cl").

... and, back to the original question ...

6. When you use headers (which you will frequently), you should *always* define
any header dependency in your "Makefile". This is crucial to insure that the
data definition in one module is always in sync with the definition in any other
module that uses the data item!

'Hope that helps .. PSM