What Dictates Which .o Files To Create When Compiling?


Gadget

Member
Joined
May 16, 2006
Messages
247
Sorry if this is a noob question (I am a C++ noob), but what actually dictates which .o files to produce? I compile and it generate shell.o and C5Sprite.o , but there are other .h / cpp files that don't result in an object file being produced. Presumably everything related goes into my shell.o, but then why would I have a seperate C5Sprite.o ?
 
If you compile foo.cpp with the -c option you will get foo.o e.g.

g++ -c foo.cpp

You can change the name with -o e.g.

g++ -o bar.o -c foo.cpp
 
It depends what you're using to control the compilation. At the bottom level, if you run the compiler by hand you tend to compile one .cpp file to one .o file; the .h files are just included by the .cpp files, so don't get separate object files of their own. Then finally you link together all the .o files that form a single application, to produce an executable. The idea is more than just to separate your code for easy browsing - it also means that if you change just one .cpp file it only needs to build the corresponding .o file and relink the executable, it doesn't need to recompile the whole project.

If you're using makefiles, you specify this explicitly in the makefile, stating which object files the executable depends on, and what their dependencies are (which .cpp file each .o file depends on). Make then runs the compiler once per object file that's out of date, and again to link everything together.

If you're using an IDE (e.g. Eclipse, Dev-C++, Microsoft Visual Studio) then the IDE usually controls the process, though some, like Eclipse, also let you write your own makefiles if you prefer. The IDE usually has the concept of .cpp files being members of a project; it then makes one .o file for each .cpp file, as above. If it's not doing this then perhaps you added the .cpp files to the wrong area of the project - sometimes they allow you to specify files as being part of a project without actually being explicitly compiled. It depends a lot on which IDE you use, though.
 
gfoot posted on Aug 17 2006 at 10:40 PM said:
It depends what you're using to control the compilation. At the bottom level, if you run the compiler by hand you tend to compile one .cpp file to one .o file; the .h files are just included by the .cpp files, so don't get separate object files of their own. Then finally you link together all the .o files that form a single application, to produce an executable. The idea is more than just to separate your code for easy browsing - it also means that if you change just one .cpp file it only needs to build the corresponding .o file and relink the executable, it doesn't need to recompile the whole project.

If you're using makefiles, you specify this explicitly in the makefile, stating which object files the executable depends on, and what their dependencies are (which .cpp file each .o file depends on). Make then runs the compiler once per object file that's out of date, and again to link everything together.

If you're using an IDE (e.g. Eclipse, Dev-C++, Microsoft Visual Studio) then the IDE usually controls the process, though some, like Eclipse, also let you write your own makefiles if you prefer. The IDE usually has the concept of .cpp files being members of a project; it then makes one .o file for each .cpp file, as above. If it's not doing this then perhaps you added the .cpp files to the wrong area of the project - sometimes they allow you to specify files as being part of a project without actually being explicitly compiled. It depends a lot on which IDE you use, though.

Thanks all!! It looks like it's something to do with CodeBlocks, and the way I added this particular file to the project. Once I work out exactly what I did, I will reply here.
 
Last edited by a moderator:
Back
Top