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
_______________________________________________
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Reply via email to