[API] Some more cleanup ideas
Stephan Bergmann
sbergman at redhat.com
Thu Nov 29 05:50:15 PST 2012
On 11/29/2012 02:16 PM, Michael Stahl wrote:
> 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...
Right, forgot about the Clang case. So that would mean keeping
SAL_THROW non-deprecated, making it a nop with Clang --disable-dbgutil
(but making it a non-nop for GCC generally), and changing the
cppumaker-generated headers to use SAL_THROW.
Stephan
More information about the LibreOffice
mailing list