It appears that the C++ standard allows overriding destructors to be marked
"override," but at least some MSVC versions complain about it, so at least make
sure such destructors are explicitly marked "virtual."
Change-Id: I0e1cafa7584fd16ebdce61f569eae2373a71b0a1
...mostly done with a rewriting Clang plugin, with just some manual tweaking
necessary to fix poor macro usage.
Change-Id: I71fa20213e86be10de332ece0aa273239df7b61a
It's not very efficient, because we generally end up copying it twice -
once into the parameter and again into the destination OUString.
So I create a clang plugin that finds such places and generates a
warning so that we can convert them to pass-by-reference.
Change-Id: I5341a6ea9e3190f4b4c05c42c85595e3dcd83361
so we can hopefully deprecate getImplementationId and make all implementations
return an empty sequence.
Change-Id: I161b5fce727541ea2c8303b5d228dbc4939a55b6
...to improve diagnosing misuses of boolean expressions in client code (cf.
compilerplugins/clang/implicitboolconversion.cxx). This change should be
transparent to client code.
Missing overloads of insert() for bool have been added to OStringBuffer and
OUStringBuffer (which required dropping one !VALID_CONVERSION check that would
now pick that overload, but would be flagged by
compilerplugins/clang/pointertobool.cxx).
Change-Id: I2d64cd923b8f47bfaa31e753def6515c29a3f8c9
This is much better approach compared to the callback function, as it allows
passing arguments to the c++ constructor directly, while still allowing some
additional initialization after having acquired the instance.
Change-Id: I5a0f981915dd58f1522ee6054e53a3550b29d624
Many of the initalizations (in eg. framework) have to be done on an
acquire()'d object, so instead of doing the initialization directly, return
the initialization member function back to the createInstance() /
createInstanceWithContext() / ... and perform the initialization there.
As a sideeffect, I belive the calling initialize() from servicemanager is not
that much a hack any more - whoever converts the implementation to be
constructor-base has the choice to provide the callback, or still initialize
through XInitialization, where the callback is preferred by servicemanager
when it exists.
Change-Id: I8a87b75c54c1441ca0f184967d31ff4902fc4081
3af99e4d59d89c343965a928681a30f36b1007d2 "convert equalsAsciiL calls to
startsWith calls" should rather have converted to oprator ==.
Change-Id: Id4a8836c5d6d570e54661c40be7214632e202b21
Most of the constructors are supposed to be only a call of
new TheInstance(arguments)
or an equivalent; so let's just change the constructor caller accordingly, to
accept unacquired new instance.
If there are exceptions that need to do more heavy lifting, they do not have
to use the constructor feature, or there can be a wrapper for the real
implementation, doing the additional work in their (C++) constructor.
Change-Id: I035c378778aeda60d15af4e56ca3761c586d5ded
There is no need to use different styles for writing the same thing.
It also makes it easier in future to use search & replace.
But of course, there are also some more complicated functions.
Change-Id: I773da20378af0e0d5a27689d3903df7063fb8ac0
...to directly call constructor functions of ComponentContext-based C++
implementations of (non-single-instance) UNO services. The case where these
calls would need to be bridged across different environments (e.g., from gcc3
to gcc3:affine) is not yet implemented.
bootstrap.component and expwrap.component are adapted accordingly as a proof-of-
concept (which had previously been adapted to use the prefix="direct" feature,
which may become unnecessary again in the end, depending on how to handle
single-instance services/singletons). More to follow.
Change-Id: I18682d75bcd29d3d427e31331b4ce8161dbb846d
...it was never meant to be called by client code anyway and is no longer needed
to be exposed since the global service manager implementation moved to
cppuhelper.
Change-Id: If2d0510b2364084d36edeb156a3459d9b8aeb983
