...in some places where it is obvious that it does not hurt that for an empty
vector the obtained pointer is not necessarily a nullptr.
Change-Id: Id5d66b1559ca8b8955d379bcdbfae6986ef46a51
...the deprecation-warning noise is getting ever louder, and eventually auto_ptr
will just disappear. Just surrender and use good-old plain pointer and deletion
in dtor---it's probably the best to do in this stable interface.
The change is backwards compatible. For one, in all relevant standard libraries
(libstdc++, even in debug mode; libc++; msvcrt) sizeof(auto_ptr<T>) equals
sizeof(T*). And for another, the removed UnoUrlDescriptor ctor was only called
from within cppuhelper and had deliberately been left out of
cppuhelper/source/gcc3.map (so isn't exported at least on Linux)---marking it
SAL_DLLPRIVATE had probably just been forgotten when retrofitting cppuhelper
with CPPUHELPER_DLLPUBLIC annotations.
Change-Id: Ic8bce29d93938f2b2e0a264baee85132668e1294
...broken with 60d60caf99a40ca0c3891bf230c5a1fdbae5f49c "Renamed XPropertySet2
to XPropertySetOption" et al
Change-Id: I684736ffafc4642548b7c24171cc52c1acb32252
AsynchronousFinalizer was originally added as
870a4401c05beec3d31c1f6055a64591edd0a9d9 "INTEGRATION: CWS mtg1: #i57753# Avoid
long-running finalize methods" referring to
<https://issues.apache.org/ooo/show_bug.cgi?id=57753> " Fix JNI-UNO bridge so
that the JVM doesn't run out of memory when a destructor locks the SolarMutex."
It is unclear to me how relevant "If JVMs are getting more mature and should no
longer have problems with long-running finalize methods, this class could be
removed again" really is in practice. After all, advice on hotspot-gc-devel is
to avoid finalize() if possible
(<http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2014-June/010215.html>
"Re: History of finalizer execution and gc progress?"). So stick with this
approach of home-grown draining for now (where a home-grown approach using
PhantomReferencens would need a dedicated draining thread, too, so would not
have much benefit over the existing code in practice).
Timely termination of AsynchronousFinalizer threads is achieved by using a
dedicated thread per bridge and joining it in the remote bridge's dispose()
resp. the JNI environment's new java_env_dispose.
Change-Id: Idcef2dbf361a1de22f60db73828f59e85711aea7
Sadly cannot forward declare "struct {...} TimeValue;".
rtl/(u)?string.hxx still include sal/log.hxx but removing osl/diagnose.h
was painful enough for now...
Change-Id: Id41e17f3870c4f24c53ce7b11f2c40a3d14d1f05
It turns out that almost none of them were necessary.
Change-Id: I1311ed28409c682b57ea8d149bcbaf2c49133e83
Reviewed-on: https://gerrit.libreoffice.org/12133
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.com>
Incorrectly converted in a384b21cc40818bf3c918951a086a30b5d9d8022
where SFX_IMPL_ONEINSTANCEFACTORY was used.
AFAICS it's the first converted single-instance service which implements
css::lang::XInitialization. That's kind of strange but can do its job.
sbergman@redhat.com: Three things were necessary in order to not call the
~ShutdownIcon code too late during exit now:
* Move the relevant code from ~ShutdownIcon to ShutdownIcon::disposing.
* Add a dummy <singleton name="com.sun.star.office.theQuickstart"/> so the
service manager will eventually dispose the (single) instance.
* In
cppuhelper::ServiceManager::Data::Implementation::createInstanceWithArguments
do not shortcut updateDisposeSingleton in that odd case of calling
createInstanceWithArguments on an implementation that (effectively) is a
singleton (as otherwise the service manager would still not dispose it). It
looks to me like that "return inst;" was an inadvertent leftover in
874c481801434d4fac3c50f076bff0fe3a3988b6 "Simplify service manager's tracking
of singletons" and wasn't intended to serve some subtle purpose.
Change-Id: Icd4d3168ec0bbb820b17ac321fe897ac9f9ce7fc
Without this, a Data::Implementation can have a circular reference of
shared_ptr to itself through .factory1
Change-Id: Ie05545e7ecc0ae85256d2c374fe79f0c678ccf64
Signed-off-by: Stephan Bergmann <sbergman@redhat.com>
Add a macro in include/cppuhelper/implbase_ex.hxx
to make initialising the type_entry classes a little less verbose.
Change-Id: I0904b5b9db269c92bc89e7ce3d6c8b09350c9897
In other words, only executable files go in the MacOS folder. Dynamic
libraries and bundled frameworks (i.e., LibreOfficePython), and
nothing else, go in the Frameworks folder, and all other files go in
the Resources folder.
Especially, note that Java class files and rc (.ini) files also go in
Resources.
Such an app bundle structure is what Apple strongly suggests one
should use, and it has been hinted that future versions of code
signing and/or Gatekeeper will require such a structure.
There is still some ugliness thanks to traces of the historical
separation of URE from "the office". Like there are two separate
"unorc" files, one for URE, one for the LibreOffice application. IMHO,
this should be cleaned up, but is probably controversial.
(Eek! I now see there are actually *three* unorc files in the app
bundle. Not intentional. Need to fix that later.)
Change-Id: Idcf235038deb5b8e1d061734993e9f31869b7606
The headers cppuheader/compbase.hxx and implbase.hxx. They have been deprecated
since 2001. Moved the definitions of the deprecated functions to
cppuhelper/source/compat.cxx.
Signed-off-by: Stephan Bergmann <sbergman@redhat.com>, adding fixes and clean-up
in cppuhelper/source/compat.cxx and odk/Package_odk_headers.mk
Change-Id: I48b3cbf551b59d72614737a883a96aab55fc2090
Find "missing headers," where a function is declared directly in the
.cxx (as extern) and not defined, and should arguably instead be declared
in an include file.
Change-Id: I6d83ee432b2ab0cd050aec2b27c3658d32ac02a2
...no reason to not have it enabled for URE C include files and what
little real C code is still left. (But note that Clang ignores that
warning.)
Change-Id: Ia6940f9f940a0c226e9b724331d65c9862ce32e6
