Determine if a function has been defined

Just summarizing it for anyone who though it was too long and didn't want to read it.

Fair enough :)

The C++ preprocessor resolves a #include statement during compilation. But that's compilation - NOT runtime.

Why doesn't it respect the order? I should think that making it chaotic would be more difficult than just linearly assembling the code...

The order of #include is respected. It has absolutely nothing to do with the order of initialization of global variables across multiple compilation units, however.

Why doesn't it respect the order? I should think that making it chaotic would be more difficult than just linearly assembling the code...

But what is that order?

I refer you to my previous question:

I have a project with 3 files, A.cpp, B.cpp, and C.cpp, which are linked together to create an application. In which order would this hypothetical global-scope code in these 3 files execute?

Assume "A.cpp" contains my main function, and B.cpp and C.cpp each define a class that is used by my application. What is the "linear order" of A, B, and C? What if, as is more likely in any decent-sized project, there are 10 files, each defining a class? 20? 100?

Last edited on

I don't know how you can link the files without include, I need this information to respond to your(Mikey's) question.

Also, what do you(L B) mean by [across] "multiple compilation units"?

A .cpp file is a single compilation unit, for instance.
Multiple .cpp files are multiple compilation units.

If you define globals in one .cpp file and more globals in another .cpp file, you cannot tell which order they will be initialized in.

#include is used to include a header file at compilation time. The header file will contain the information other translation units (i.e. files) will need in order to use the symbols contained in it, but no more. It (ideally) won't contain the actual code for the functions/methods it declares.

Linking is a different issue - it happens after compilation, and it takes the object files that were created during the compilation, and links them together so that the compiled code in one file can access compiled code in other files.

Really, we're into basic C++ tutorial stuff here. If you're interested, you'd be better off finding an existing tutorial and reading it, rather than asking us to regurgitate one for you.

Last edited on

Note that compilation units and translation units are directly related ;)

In my project, I have:

#include "ReadFile.cpp"
#include "Data.h"

Area Window;
Area View;
Camera cam;

#include "ControlEvents.cpp"
#include "Controls.cpp"

'Controls' relies on 'ControlEvents', 'Data.h', and the globals in the centre. Are you telling me that if I keep compiling this without changing anything, one time 'Controls' might try to use "cam", but it hasn't been initialized yet in this particular compilation? I just can't see that being true, but that's what I'm getting from it.

Last edited on

No. I'm saying that if cam relies on View, you cannot rely on View having been created before cam.

I don't mean to sound rude, but the fact that you have #include statements including .cpp files indicates to me that you don't really understand the basics of C++. I reiterate my previous statement - there's already loads of C++ tutorial material out there to introduce you to the basics of the language, if you're interested. There's no need for us to repeat it here.

@krakow10 In C++, you do not #include .cpp files. You give them all to the compiler, you do not #include them.

Why does it work if that's not what I do?
I'm so confused now
:?
How do I include them if I don't include them?

You have to specify them all when you compile from the command line, or in an IDE just add them to your project.

It worked because you were lucky.