Hello, I've just found out that exception specification on functions in LO have been just pretty comments, for about 10 years.
Just to make sure what I'm talking about, it's the throw() in e.g. this void foo( int a, void* b ) throw( css::uno::RuntimeException ); which says what exceptions a function can throw. I found out by compiling LO with Clang, running it and having it crash where gcc-compiler version had no problem. Stephan Bergmann and repo history revealed that in 2001 -fno-enforce-eh-specs was added to gcc's flags, turning off code generated that ensures these specifications are actually followed (and MSVC has reportedly never cared). Clang does not have the option. I've already actually fixed the problem (in vbahelper/inc/vbahelper/vbaccesshelper.hxx) and it appears the specifications somehow magically haven't rotten, as now LO runs fine for me (as far as I can say, I can't test everything). That however brings up the question of what the specification are for in the codebase. The 'Deprecated Exception Specifications, Added noexcept' part of http://herbsutter.com/2010/03/13/trip-report-march-2010-iso-c-standards-meeting/ is quite interesting read, the summary is: - the specifications enforce that disallowed exceptions are not thrown at runtime, adding code to each such function to check it, thus actually making the performance worse - boost, and pretty much everybody else it seems, do not consider it worth the hassle of specifying what a function may or may not throw, except for flagging a non-inline method as not throwing any exception at all as a means of optimization for places where such functions are called - C++11 deprecates it and instead introduces a noexcept keyword which forbids the function to throw anything I'm not strongly biased either way, but what we have right now are really just pretty comments on functions. I think we should either say that we use the specifications, in which case -fno-enforce-sh-specs should not be used at least in debug builds, or we can say we follow the C++11/Boost/etc. trend and not use them, in which case we can have one macro for portable way of saying noexcept and have an EasyHack for removing the other specifications. BTW, it should be also noted that SAL_THROW() expands to nothing with gcc. Opinions on this? -- Lubos Lunak l.lu...@suse.cz _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice