This is mostly right. But it is possible to write functions 'inline',
which is a hint to the compiler to substitute the function call with the
body of the function. This can lead to a performance increase in some
circumstances, but may increase the size of the generated code.
The compiler needs to see the body of the function in any translation unit
that calls it if it is going to inline it, so inline functions have to go
in the header (or be included by it). It is still preferable to define them
outside the class, though:
// in header
class Class
{
void Foo() { /* do something */} // implicitly inline, like C#.
void Bar();
};
// explicitly inline - preferred
inline Class::Bar()
{
/* do something */
}
Inlining is a *hint*. The compiler will ignore it for complex functions.
And to do it routinely is an early optimisation which, as we all know,
is the root of all evil.
Just remember: "headers" are a convention for source code organization -
nothing more.
This is very bad advice, and plain wrong in some circumstances (see below).
C++ has a one-definition rule. Try putting the body of a non-inline
function in a header and including it in more than one translation unit.
The linker will not link.
The semantics of inline code are different in Java and C#. Don't be misled.
In C++ it is an explicit hint to the compiler, which it is free to ignore.
In Java and C# it is just the way the code must be organised - a serious
design flaw IMO because this mixes the interface with the implementation.
I don't know whether any actual inlining occurs or not.
[FWIW, I can't understand why the designers of these languages did not
adopt the Pascal notion of a single file but still separating interface
from implementation. This is a strength in Delphi code.]
This is the style used by the Windows Forms wizards (and the examples)
because they were designed for C# which does not use separate files for
declaration and definition.
Which is the same as saying that MS don't understand or don't care about
C++. C++Builder has a superior forms based IDE and maintains a proper
separation of H and CPP code, so it is obviously possible. Different
languages have different requirements. It is ridiculous to say "one size
fits all."
There's no magic set of rules for what "needs" to be in a header and what
"needs" to be in a CPP file.
There most definitely are such rules. For example a static data member must
be defined somewhere (the header contains a declaration). This must be in
a single translation unit because of the one-definition rule. This basically
means you must stick it in one of your CPPs.
I'd suggest the book "Large Scale C++ Software Design" by John
Lakos, or "Code Complete" by Steve McConnell.
This is very good advice. Not only are there a few rules which must be
followed, but there are a great many "best practice" ideas which lead to
better separation and reduced dependencies between translation units.
Lakos is particularly valuable in this regard.
Don't get too bogged down by this. You won't go far wrong if in your mind
you map Delphi's interface section to a header, and the implementation
section to a CPP.
Finally, I'd give Managed C++ a miss altogether if I were you and learn C#
instead. Use Standard C++ for C++ projects, not the kludge that MS has
created, which is emphatically NOT C++. C## would be a better name.
Arnold the Aardvark
'And no, C++ does not have "garbage collection".
Thank God for that. C++ gives me the ability to not
create garbage in the first place.' - Ed Mulroy
