This may reduce some degree of dependency on boost.
Done by running a script like:
git grep -l '#include *.boost/scoped_array.hpp.' \
| xargs sed -i -e 's@#include *.boost/scoped_array.hpp.@#include <memory>@'
git grep -l '\(boost::\)\?scoped_array<\([^<>]*\)>' \
| xargs sed -i -e 's/\(boost::\)\?scoped_array<\([^<>]*\)>/std::unique_ptr<\2[]>/'
... and then killing duplicate or unnecessary includes,
while changing manually
m_xOutlineStylesCandidates in xmloff/source/text/txtimp.cxx,
extensions/source/ole/unoconversionutilities.hxx, and
extensions/source/ole/oleobjw.cxx.
Change-Id: I3955ed3ad99b94499a7bd0e6e3a09078771f9bfd
Reviewed-on: https://gerrit.libreoffice.org/16289
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
rtl/string.hxx and rtl/ustring.hxx both unnecessarily #include <sal/log.hxx>
(and don't make use of it themselves), but many other files happen to depend on
it. Cleaned up some, but something like
grep -FwL sal/log.hxx $(git grep -Elw \
'SAL_INFO|SAL_INFO_IF|SAL_WARN|SAL_WARN_IF') -- \*.cxx)
shows lots more files that potentially need fixing before the include can be
removed from rtl/string.hxx and rtl/ustring.hxx.
Change-Id: Ibf033363e83d37851776f392dc0b077381cd8b90
ie.
void f(void);
becomes
void f();
I used the following command to make the changes:
git grep -lP '\(\s*void\s*\)' -- *.cxx \
| xargs perl -pi -w -e 's/(\w+)\s*\(\s*void\s*\)/$1\(\)/g;'
and ran it for both .cxx and .hxx files.
Change-Id: I314a1b56e9c14d10726e32841736b0ad5eef8ddd
...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
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
