Efficient UNO component linkage & GC ...

[Matúš Kukan]

Hi Stephan,

some great work, thanks.

On Thu, 2013-12-19 at 10:51 +0100, Stephan Bergmann wrote:
> thought-dump:

really helps :-)

> * assume all LO-internal C++ implementations are ComponentContext-based 
> (i.e., use cppu::createSingleComponentFactory or 
> cppu::createOneInstanceComponentFactory rather than legacy 
> ServiceManager-based cppu::createSingleFactory or 
> cppu::createOneInstanceFactory); reaching this state is effectively an 
> easy hack

Yep, but maybe we don't need special easy hack for this.
So far, I was able to just remove the variables as unused.
I think it's easy to do as part of creating constructor function for
implementation.

> * implementations of non-single-instance services can be rewritten using 
> the new .component XML <implementation constructor="..." feature, cf. 
> <http://cgit.freedesktop.org/libreoffice/core/commit/?id=ae3a0c8da50b36db395984637f5ad74d3b4887bc> 
> "Add .component <implementation constructor='...' feature"; this is 
> effectively an easy hack (note that service manager's 
> createInstanceWithArguments[andContext] no longer uses the 
> css.lang.XInitialization protocol on those implementations)

Hm, what does it mean, it no longer uses css.lang.XInitialization
protocol?
What to do about implementations inheriting from XInitialization?
I tried to convert such class in
https://gerrit.libreoffice.org/#/c/7186/
Does it look good ?
If it's clear when to assert for arguments->nElements and what to do
about initialize() we should create an easy hack for this I think.

> * for implementations of single-instance services/singletons, we can:

Sorry, no opinion on this from me. ;-)

> ** note that there are always situations where UNO services are not 
> called via constructor, though; e.g., the constructor-less 
> css.uri.UriSchemeParser_* services are always created via dynamically 
> computed name

Ah, good to know we need to care about such cases.

> * idea is to set aside for every UNO service/singleton S two macros 
> LO_URE_CTOR_ENV_<S'> and LO_URE_CTOR_FUN_<S'>, and a macro 
> LO_URE_CURRENT_ENV, and modify cppumaker to generate constructor code as
> 
> > #if defined LO_URE_CURRENT_ENV && defined LO_URE_CTOR_ENV_<S'> \
> >     && defined LO_URE_CTOR_FUN<S'> && LO_URE_CURRENT_ENV == LO_URE_CTOR_ENV_<S'>
> >
> > extern "C" cppu::ConstructorFunction_type LO_URE_CTOR_FUN<S'>;

Is not LO_URE_CTOR_ENV_<S'> redundant ?
We can just check for defined LO_URE_CTOR_FUN<S'> ?

> ** when compiling .cxx files for which it is known that the constructor 
> function for some S will be visible (which could e.g. be ~always the 
> case when compiling for a single big executable on Android/iOS), define 
> the LO_URE_CTOR_ENV_<S'> and LO_URE_CTOR_FUN_<S'> macros, either via -D 
> or via some strategically included header

Yes, so this needs some thought.
If I see correctly, there are already some typos in
15abebbde560e17413f17b16b8b2e9c1f31f01a5
like LO_URE_CTOR_FUN_com_dot_sun_dot_star_dot_xml_dot_sax_dot_FastParser
vs.
LO_URE_CTOR_FUN_com_dot_sun_dot_star_dot_comp_dot_extensions_dot_xml_dot_sax_dot_FastParser

Unfortunately I can't see how to avoid these macros, so I'll try to
generate include/osl/detail/component-defines.h early in build process.
Do you have another idea ?

Overall, this looks really good,
Thanks,

Matus