[SOLVED] C++, building a binary, file inclusion...
ProgrammingThis forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Hi, I wonder if someone can help me with this, it's a simple but yet important problem.
I'm trying to learn C++ and now I'm studying multiple file codes. I've learned that I can use pre-processor to deal with multiple file inclusions and stuff (#ifndef #define #endif), but I have noticed something and I don't know how to solve it.
Let's say that we have 3 files: MyClass.hpp (containing prototypes), MyClass.cpp (containing class definition), and main.cpp
Obviously both main.cpp and MyClass.cpp should have: #include "MyClass.hpp".
Here's the problem, I'm learining to compile to obtain object files (*.o) and then link them together but I noticed that binary (exe) files are larger when doing this than when compiling to exe directly a single file with all the code inside (all code in main.cpp). I think this is because prototypes are only compiled once when doing this, but when using multiple files both object codes main.o and MyClass.o will have compiled an "instance" of the MyClass.hpp prototype file since include guards only protect from redefining in each file individually (or at least the way I'm doing it, compiling each file individually like this: g++ -c file.cpp) and then linking them together: g++ file1.o file2.o file3.o...
Your .hpp files should not be creating any storage at all, just defining things for the .cpp files. If you have code or data defined in the .hpp files, then move it to a cpp where it will only be created once.
If that's not it, then maybe you are including duplicate library code into both .o files. That would mean that your compiler options are wrong.
If THAT's not it then maybe it is only a little bit larger? When linking two separate .o files there may be some glue involved to do long jumps between separate compilations and to store external symbols. That's ok.
actually it depends on the content of the files, so right now I cannot decide. Theoretically splitting a source file into two parts will not modify the result (or just a bit), but there are so many tricks, so many possibilities.
Your .hpp files should not be creating any storage at all, just defining things for the .cpp files. If you have code or data defined in the .hpp files, then move it to a cpp where it will only be created once.
right, and actually generating code or data from header files is considered bad style. Header files should only contain symbol definitions and declarations.
Quote:
Originally Posted by smallpond
If that's not it, then maybe you are including duplicate library code into both .o files. That would mean that your compiler options are wrong.
If THAT's not it then maybe it is only a little bit larger? When linking two separate .o files there may be some glue involved to do long jumps between separate compilations and to store external symbols. That's ok.
Or the thread starter has debugging info included in his object and executable files (e.g. symbol tables or line number/code address xref tables). If there's information about external symbols as well, that info may get duplicated.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.