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
ListBox and related now handle up to sal_Int32 elements correctly.
sal_Int32 instead of sal_Size or size_t because of UNO and a11y API.
Also disentangled some of the mess of SvTreeList and other containers
regarding sal_uInt16, sal_uLong, long, size_t, ... type mixtures.
Change-Id: Idb6e0ae689dc5bc2cf980721972b57b0261e688a
Reviewed-on: https://gerrit.libreoffice.org/8460
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Eike Rathke <erack@redhat.com>
The time when it made sense to use "clever" #ifdefs to, for performance or
compiler reasons, conditionally bypass private parts of a class declaration
passed a decade or longer ago.
Still more of this in sw and sc. People working on those modules might want to
do it too, or not.
Change-Id: I1053139ca5e5e2631f7b22d99d3bada54fc337be
Reviewed-on: https://gerrit.libreoffice.org/3627
Tested-by: LibreOffice gerrit bot <gerrit@libreoffice.org>
Reviewed-by: David Tardon <dtardon@redhat.com>
Tested-by: David Tardon <dtardon@redhat.com>
see https://gerrit.libreoffice.org/#/c/3367/
and Change-Id: I00c96fa77d04b33a6f8c8cd3490dfcd9bdc9e84a for details
Change-Id: I199a75bc4042af20817265d5ef85b1134a96ff5a
