views:

291

answers:

7

Becase I've seen (and used) situations like this:

In header.h:

class point
{
public:
    point(xpos, ypos);
    int x;
    int y;
};

In def.cpp:

#include"header.h"
point::point(xpos, ypos)
{
    x = xpos;
    y = ypos;
}

In main.cpp:

#include"header.h"
int main()
{
    point p1(5,6);
    return 0;
}

I know the program executes from main, but how does the compiler know what order to compile .cpp files? (Particularily if there are more than one non-main .cpp files).

A: 

Usually you compile them separately yourself (or with a build tool like make). The header file allows you to compile them in any order. If you do compile them together, the order is probably the order that you pass to the compiler command, but it doesn't actually matter, they are all eventually linked into one executable.

Zifre
+1  A: 

The order of compilation does not matter. Everything is compiled by the compiler, which uses the .h files to make sure that the symbols you are using are at least declared. It's the job of the linker, which executes after the compiler finishes, to actually match your method calls to their implementations.

Marc W
+4  A: 

If you include them in two different cpp-files it's no problem. If you include the same header twice, you get errors for duplicated definitions.

You should use include guards to circumvent that.

On top of your file, before any code:

#ifndef HEADER_H_ //every header gets it's own name
#define HEADER_H_

On the bottom:

#endif
ebo
I'm voting this up b/c its an important pattern that contributes to this discussion and adds a lot of value IMO.
jdt141
No: the OP is asking about the sequence in which several CPP files are compiled (the correct answer being that the sequence in which they're compiled doesn't matter, since they're compiled independently); the OP isn't asking about the sequence in which header files are included in each CPP file.
ChrisW
+8  A: 

The compiler doesn't care - it compiles each .cpp file into .obj file, and the .obj files each contain a list of missing symbols. So in this case, main.obj says "I'm missing point::point".

It's then the linker's job to take all the .obj files, combine them together into an executable, and make sure that each .obj file's missing symbols are available from one of the other .obj files - hence the term "linker".

RichieHindle
There usually .o files, not .obj (but it doesn't actually matter).
Zifre
They're not "usually" anything. GCC generates .o files by default, Visual Studio generates .obj. Neither is more "usual" than the other.
jalf
A: 

This is why you see #ifndef HEADER_H and #define HEADER_H at the top of some header files. The notion of only one inclusion of each header file as described here for example.

JP Alioto
+1  A: 

The compiler does not need to know what order to compile .cpp files in.

The linker sorts all of the separately compiled .o (build from .cpp) files out and resolves everything into one executable.

Macker
A: 

This is an example of Graph Theory application. The compiled modules contain relative offsets for all code blocks and its up to the linker to spot the dependencies (graph) while it constructs the executable file.

Nick D