On 29/11/12 14:05, Stephan Bergmann wrote:
> On 11/29/2012 12:37 PM, Michael Stahl wrote:
>> On 29/11/12 01:54, Thorsten Behrens wrote:
>>> * cleansed cppumaker of dead code, RTL_CONSTASCII verbosity, and
>>> writing out exception specs
>>
>> iirc we want to remove C++ exception specifications for production code
>> because they don't make sense there - but would it make sense to keep
>> them in --enable-dbgutil mode? could be useful for debugging... after
>> all if an exception that isn't documented is thrown that's still a
>> violation of the API contract.
>
> Just noted that solenv/gbuild/platform/com_GCC_defs.mk already does
> that, setting -fno-enforce-eh-specs unless --enable-dbgutil.
> The above does not match well with SAL_THROW as currently defined in
> sal/types.h: The latter expands to nothing for GCC and to throw (...)
> for MSC. The intention behind that was the same as what has been
> discussed above, to avoid the additional unexpected-checks emitted by
> the compiler in production code (likely GCC did not have
> -fno-enfore-eh-specs back then, Sun CC had to be catered for too, and
> MSC was definitely always violating the Standard back then by
> effectively ignoring any exception specifications). So I think it makes
> sense to deprecate SAL_THROW in favor of plain exception specifications.
> (So this obsoletes my other mail asking to "keep the exception
> specifications as SAL_THROW comments.")
also iirc LLVM/clang has no option similar to -fno-enfore-eh-specs, i.e.
it always enforces exception specifications, so if we were to use that
for product builds (no i am not proposing that :) ), we'd need to not
generate the throw in cppumaker or use some macro to nerf it...
>>> There remain the following open questions:
>>>
>>> * should we keep ~MyClass() {} throw() - or rather have just one
>>> single proper virtual ~XInterface() {} throw in the base class
>>> (note the missing virtual all over the place) - or bin all
>>> exception specs unconditionally?
>>
>> "throw ()" on a destructor does not hurt imho - it is not allowed to
>> throw anything in practice...
>> i'm not aware of any problems by relying on default dtor in derived
>> classes, but i'm sort of a mere user of C++ so what do i know anyway...
>
> The explicitly mentioned dtors in derived classes are there to "avoid
> warnings about virtual members and non-virtual dtor" (made necessary by
> the design bug of not having a virtual dtor generated for XInterface).
ok i missed that XInterface also has no virtual dtor, and if we add one
now it will break C++ ABI completely, so we're stuck with the status quo
on that...
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
