Date: prev next · Thread: first prev next last
2012 Archives by date, by thread · List index


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.
solenv/gbuild/platform/com_MSC_defs.mk strangely uses -EHa (catching SEH 
exceptions in addition to C++ exceptions) instead of -EHs (catching just 
C++ exceptions) or even -EHsc (in addition, assume C functions to never 
throw).  I don't know whether MSC has a switch these days similar to 
GCC's -fno-enforce-eh-specs (i.e., to avoid emitting code that catches 
unexpected exceptions and diverts to std::unexpected) -- IIRC it 
traditionally behaved like that per default, but I think that Standard 
violation got fixed eventually?
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.")
And to keep us honest, it probably makes sense to keep exception 
specifications in cppumaker-generated headers after all.  The 
implementations of those functions need to adhere to the corresponding 
UNOIDL method raises-clauses anyway (when interacting with other UNO 
environments, or even with old C++ UNO code), and having them checked at 
runtime in --enable-dbgutil builds helps identify design bugs in the API 
(see e.g. <https://bugs.freedesktop.org/show_bug.cgi?id=57611#c6> 
"report builder design mode CRASH on change FixedLine height to zero").
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).
Stephan

Context


Privacy Policy | Impressum (Legal Info) | Copyright information: Unless otherwise specified, all text and images on this website are licensed under the Creative Commons Attribution-Share Alike 3.0 License. This does not include the source code of LibreOffice, which is licensed under the Mozilla Public License (MPLv2). "LibreOffice" and "The Document Foundation" are registered trademarks of their corresponding registered owners or are in actual use as trademarks in one or more countries. Their respective logos and icons are also subject to international copyright laws. Use thereof is explained in our trademark policy.