Functions defined in the body of the code in a .h file end inlined:
Foo.h:==================================
class Foo {
public:
int blah() { return 1; } // this is inline inserted into caller
inline int blah2() { return 1; } // exactly the same
int blah3(); // defined once by C file
int blah4(); // this is ok due to inline
int blah5(); // this one will cause problems
};
inline int Foo::blah4() { return 4; } // okay due to inline
int Foo::blah5() { return 5; } // bad, will multiply-define it for each
use of .h file!
int func1() { return 1; } // do not do this, it will be multiply defined
inline int func2() { return 2; } // ok
static int func3() { return 3; } // may appear to work, but don't do this!
int func4(); // this is ok, means same as extern
extern int func5(); // but many prefer this
Foo.c:===================================
int Foo::blah4() { return 4; } // ok, only defined once
int func4() { return 4; }
int func5() { return 5; }
On 09/23/2011 08:59 AM, Greg Ercolano wrote:
> I hope I haven't asked this one before:
>
> Does it create any kind of ABI issue if one moves
> a class method's code implementation from the .H file
> to the .cxx file? (ie. doesn't change the calling params
> or return value, just moves the code from one to the other)
>
> I'm sure the compiler/linkers handle this 'the right way',
> but it occurs to me I'm not sure what the compiler does when
> code is implemented in the .H; does it get compiled each time
> it's #include'd, then sorted out at link time?
>
> If so, in the case of a class that's entirely implemented in a .H,
> what happens when an app is built against a new version of the lib,
> but runs in an environment that dynamically links against an older
> version of the lib?
>
> I imagine the runtime link is going to choose only one implementation
> of the method code, and use it consistently for both the lib and the
> app code that uses it, and I /imagine/ it chooses code that was built
> into the lib? (So that the runtime lib controls which version of the
> code is used, and not some mix of new and old code?)
_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev
