03-16-2018, 09:18 PM
(This post was last modified: 03-17-2018, 09:31 PM by Brian Beuken.)
"So when I include xxx.h, xxx.cpp is included also for compiling?"
not quite, you are making xxx.obj and the xxx.cpp file contains all the code, and xxx.h is the definitions of the code in that xxx.cpp file, once the obj is successfully made, it is put to one side
Now suppose xxx.cpp contains the class MyObject.
the xxx.h file, should really be called MyObject.h
But it was compiled ok, that means we have MyObject.obj and the code to make MyObject's exists
If we now take another file, like our bootstrap file, containing main()
if we want to do something like
main()
{
MyObject MO; // create an instance of an obj
}
Then clearly the main.cpp file has no idea what a MyObject is... its never heard of it before, so it will complain, out of scope, or undefined.
but..
#include "MyObject.h"
main()
{
MyObject MO; // create an instance of an obj
}
tells the main.cpp file, that there are things called MyObject and now it knows what they are made of, the definition of them is in the MyObject.h file.
The code for them is still very much in the MyObject.obj file, but main.cpp can compile and make a MyObject called MO...which it can then use. The compiler is trusting that the MyObject class is properly defined, and puts markers in the main.obj wherever there is a use of MyObject, for the linker to fill in, because its job is to take all the obj files and fill in the blanks.
When the linker comes along it has main.obj, and MyObject.obj and fills in the markers with the correct code, if the files are properly used and no extra undefined or mis defined usage has occurred, the 2 objs are combined into 1 executable file and we're good to go.
That's a simply way to think of the build process, edit, compile, link...run.
not quite, you are making xxx.obj and the xxx.cpp file contains all the code, and xxx.h is the definitions of the code in that xxx.cpp file, once the obj is successfully made, it is put to one side
Now suppose xxx.cpp contains the class MyObject.
the xxx.h file, should really be called MyObject.h
But it was compiled ok, that means we have MyObject.obj and the code to make MyObject's exists
If we now take another file, like our bootstrap file, containing main()
if we want to do something like
main()
{
MyObject MO; // create an instance of an obj
}
Then clearly the main.cpp file has no idea what a MyObject is... its never heard of it before, so it will complain, out of scope, or undefined.
but..
#include "MyObject.h"
main()
{
MyObject MO; // create an instance of an obj
}
tells the main.cpp file, that there are things called MyObject and now it knows what they are made of, the definition of them is in the MyObject.h file.
The code for them is still very much in the MyObject.obj file, but main.cpp can compile and make a MyObject called MO...which it can then use. The compiler is trusting that the MyObject class is properly defined, and puts markers in the main.obj wherever there is a use of MyObject, for the linker to fill in, because its job is to take all the obj files and fill in the blanks.
When the linker comes along it has main.obj, and MyObject.obj and fills in the markers with the correct code, if the files are properly used and no extra undefined or mis defined usage has occurred, the 2 objs are combined into 1 executable file and we're good to go.
That's a simply way to think of the build process, edit, compile, link...run.
Brian Beuken
Lecturer in Game Programming at Breda University of Applied Sciences.
Author of The Fundamentals of C/C++ Game Programming: Using Target-based Development on SBC's
Lecturer in Game Programming at Breda University of Applied Sciences.
Author of The Fundamentals of C/C++ Game Programming: Using Target-based Development on SBC's