[API] Some more cleanup ideas

[Michael Stahl]

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...