...to ease the implementation in C++ code of constructor-based <implementation>s that shall be single-instance (and which would have been implemented with e.g. cppu::creaetOneInstanceFactory for non--constructor-based <implementation>s). See e.g.6e35794cad"terminate XDesktop properly in unit tests" and6362ebab29"dbaccess: create instances with uno constructors" for the clumsy approach used until now, where the C++ constructor function uses a static instance that is cleared in dispose(), adding fake <singleton> entries to <implementation>s where necessary so that the ServiceManager will call those XComponent::dispose() functions when it itself gets disposed. For every <implementation>, the ServiceManager already holds an Implementation data structure, so it can easily hold a singleInstance there and clear it when the ServiceManager gets disposed. (One consequence is that single-instance implementations are now created with their Instance.mutex locked, but that should not cause problems in practice, given that the construction of a single- instance implementation should not recursively request its own construction anyway.) The new single-instance="true" attribute is mostly useful in combination with the constructor attribute (see above), but it can also be used for non-- constructor-based <implementation>s, at least in theory. (The single-instance="true" attribute is orthogonal to <singleton> elements. There are existing single-instance services---even if those should arguably have been defined as singletons in the first place---that can benefit from single-instance="true". And there are <implementation>s that support one or more <singleton>s alongside one or more <service>s, where the latter are not single-instance.) This new single-instance="true" attribute in *.component files should not interfere with the lo_get_constructor_map machinery in the DISABLE_DYNLOADING branch of cppuhelper::detail::loadSharedLibComponentFactory (cppuhelper/source/shlib.cxx) used by Android, iOS and some fuzzer code. AFAIU, the lo_get_constructor_map machinery should only ever come into play after the ServiceManager has decided whether or not to create a new instance based on the single-instance attributes in the *.component files. This commit only provides the new single-instance="true" attribute. Actual changes of <implementation>s and their C++ constructor functions are delegated to a series of follow-up commits. (So that they can easily be reverted individually should the need arise.) Change-Id: Iea6c0fc539d74477b7a536dc771b198df6b0510e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103734 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Helpers for using cppu in C++, e.g. templates for implementing UNO components, bootstrapping stuff. Get UNO up and running. See also: [http://wiki.openoffice.org/wiki/Uno/Cpp/Modules/CPPUhelper]