On 09/25/11 13:09, Bill Spitzak wrote:
> Inline is only implied if the method is defined inside the class
> definition.
Right, clear on that now.
What's interesting are the implications this has on dynamic libs;
code changes made to lib methods implemented in .h won't be 'seen'
by 'old' dynamic apps running with the new lib installed,
whereas changes made to methods implemented in .cxx
/will/ be seen by the app at runtime.
Or so my tests on linux seem to show, where I made a small
dynamic lib with 3 methods called a/b/c:
> a() implemented in .h
> b() implemented in .h as 'inline',
> c() implemented in .cxx file
When I make changes to the lib, and run the old app
with the new dynamic lib present, I get this behavior
at runtime:
o Calls to a() runs the old lib code
o Calls to b() runs the old lib code
o Calls to c() runs the new lib code
What's interesting is that even when the new lib
calls a() and b(), the new lib runs the OLD code.
This seemed surprising to me, even for the 'inline' method!
I would have expected that the lib's calls would
have invoked the new method code, and the app would
get the old code.
So apparently in this way, inline methods really aren't
'inline'; the run time linker can still force the lib
to call the older method code. I guess that ensures
'consistency' at least.
Anyway, I guess it's /not/ an issue to move code
from .h -> .cxx during a minor release of a dynamic lib;
it seems to have no effect on older apps, which continue
to run the older code.
I guess having code in .cxx gives devs more flexibility
during minor releases; one doesn't have to be concerned
as much with code incompatibilities that can be caused
if some methods are in .h, some in .cxx, and both are changed.
_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev
