Re: Efficient UNO component linkage & GC ...

On 12/23/2013 06:44 PM, Matúš Kukan wrote:
> On Thu, 2013-12-19 at 10:51 +0100, Stephan Bergmann wrote:
> > * 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.

Not sure what you mean here with "remove the variables as unused."

> > * 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/

Yes, using the XInitialization protocol inside the constructor function 
is a possibility here.

> > * 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'> ?

Not in general.

> > ** 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

Ach, sure, that quick-n-dirty include/osl/detail/component-defines.h is 
just nonsense; it erroneously uses implementation names instead of 
service names for those LO_URE_CTOR_{ENV,FUN}_<S'> macros.

> 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 ?

Introducing include/osl/detail/component-defines.h was just a quick and 
dirty hack to get this bootstrapped.  Ultimately, we likely will not 
want to have those

> #if defined ANDROID || defined IOS //TODO
> #include <osl/detail/component-defines.h>
> #endif

lines in the generated .hpp files anyway, but I do not have any more 
concrete ideas yet than that hand-waving "either via -D or via some 
strategically included header" (same for the "the encoding of 
environments (which are normally strings) in LO_URE_CURRENT_ENV and 
LO_URE_CTOR_ENV_<S'> macros must be such that they can be used in the 
preprocessor == expression above" issue).

Stephan