Does it make any difference in the compiled result and performance if I split my code in more than one .cpp file inside a project which are connected together by headers? Or is it exactly the same as a single .cpp file with the same declarations and functions?
If there's no difference then why can't I define an inline function (which is said to be better than a #define macro) that is executed in another .cpp file of the same project (or am I simply making a mistake) which works when I'm writing a single .cpp file?
Is there any way to split a .cpp file into separate files which are treated together as one .cpp file for a better overview? I'm using Code::Blocks.
I am a little confused with this structure that is new to me and I appreciate any help of you.
There is no impact on the result whether you have one or several files. Having multiple files will improve your compilation time as some of the files may not need to be recompiled though. Also, it is good to separate code into logical modules.
Inline functions should be defined in a header, if I recall correctly. Do you? I really can't say what the problem is with the little information you give..
Code is grouped into translation units (generally the aftermath of what is inside of a implementation file plus whatever is included and other preprocessing inside of that file) which in turn get compiled into object files(generally suffixed with .o). These objects are then linked together (using some hax I don't understand nor have I cared to thus far) to create an executable. As I understand it, there is no difference *in result* between having multiple translation units and a single one. However, when your project is large, having to compile the entire project every time you add a new feature can be bothersome. Generally, you have the ability to compile only object files that have changed which saves epic amounts of time during compilation. Believe you me, I probably wouldn't be using Boost if this wasn't the case. I know this probably doesn't answer your questions but there's reason for that.
Can you restate your second paragraph? I just can't make sense of it.
Please note that splitting up files can be highly confusing and even cause problems in C++. It's one of the few things some people don't like about C++. Most do not feel that include macros and headers do a good job of creating an interface to object files. In D and Java, they simply refer directly to the implementation. C++ is not designed for this and it looks terribly ugly. You could (technically) include implementation files but in reality, this simply isn't efficient. Including a file is generally a copy paste method. In a type of design, when you include a file, it usually include declarations with no implementation at all that can be determined before runtime. This causes minimal impact on binary size while still providing efficient interface to the implementation. Some libraries don't do this simply because of the inconvenience of compiling or because it can be avoided by design if used properly.
Inline functions should be defined in a header, if I recall correctly. Do you? I really can't say what the problem is with the little information you give..
So inline functions should have not just their prototype but also their entire body in the header? My code looked like this:
Header: inlinebool doSomething();
CPP file:
1 2 3 4 5
inlinebool doSomething()
{
...
returntrue;
}
Other CPP file:
1 2 3
...
if(!doSomething()) returnfalse;
...
I don't have the original code anymore. If the example above is correct then I'll have to wait until I meet the same problem again to show you the code. Maybe it was just another mistake.
Oh, and another inline-function related question: As far as I know, class members are inline by default. Does that mean that I have no performance loss if I use object oriented programming via classes and structs instead of classic programming with global variables?
I'm using class pointers and the "->" operator. Does this make any performance difference to the non-pointer use with the "." operator?
Is the MinGW compiler capable of such an optimization? Is it enabled by default or do I have to set some command lines?
Can you restate your second paragraph? I just can't make sense of it.
Sorry, I've tried to make it more understandable now:
I've declared an inline function in a header and wrote the implementation in its .cpp file. But executing it in another .cpp file of the same project resulted in an error. Executing it in the same .cpp file didn't cause any trouble. You can see an example in my last post.
But I'm not sure if the inline function caused the trouble. You can ignore it, I'll repost here if I get the same problem again.
Can you define inline please? I'm uncertain that you know what it is...
The difference between inline and non-inline functions is that the content of the inline functions will be copied to where the function is executed and the content of normal functions are stored in a kind of function stack. While the content of inline functions is in the program flow itself, the content of normal functions has to be read from the stack which takes longer. Please correct me, if I'm wrong.
The MinGW compiler is quite godly. It optimizes things that aren't possible to optimize (I kid, I kid).
So this is a positive answer to my questions in the last paragraphs? I'm glad to hear that I'm working with a good compiler even though it's free.
Do I have to set some command lines to get the full optimization potential in object oriented structures?
Seems to sum up most of your questions...
To why your code doesn't work: http://www.parashift.com/c++-faq-lite/inline-functions.html#faq-9.6
BTW, that comment was a joke (in poor taste which is why it was changed). Generally, the two king compilers are VC++ and GCC. Others generally have some problem (license, not free for use, not stable, so on) that prevents them to being compared. Clang is probably the next runner up besides those two. There are also endless optimizations (LLVM-GCC, DragonEgg plugin, branches of GCC, so on...) to GCC that head in a specific direction. VC++ not so much as it's closed source and generally not to portable/extensible anyways... In my opinion, GCC is like the C/++ compiler god.
The joke was how people often talk about optimizations on the two compilers that are either not possible or just plain pointless.
Okay, all questions related to the inline functions and the project structure are answered. Thank you.
But I'm still unsure about how object-oriented programming affects the performance and if the compiler still gets the same result for the following two code examples (thus the talking about optimization): One is in the classic style and the another one object oriented.
My question is whether these codes have the same performance or not, because they are actually the same: Allocating Memory for two variables, initializing the variables to certain values, reading the value from one variable and Deallocating the Memory.
1 2 3 4 5 6 7 8 9 10
#include <iostream>
int main()
{
int book_id;
int book_pages; // the same as creating the class below
book_id = 1;
book_pages = 500; // the same as the constructor below does
cout << book_pages; // reading a variable
return 0;
}