Re: [eigen] exception specifications...

[Hauke Heibel <hauke.heibel@xxxxxxxxxxxxxx>]

Interesting read. To summarize, I read it such that one camp claims
"theoretically all possible with zero overhead" and the other camp is
sort of telling "we have not yet implemented it with zero overhead and
it's tricky". I totally understand both sides and actually would not
have even thought about this change if the ISO C++ committee did not
decide to deprecate exception specifications - this is a tiny place,
where we can start adopting the new standard with only very little
effect on the users.

- Hauke

On Mon, Apr 19, 2010 at 6:17 AM, leon zadorin <leonleon77@xxxxxxxxx> wrote:
> On 4/18/10, Hauke Heibel <hauke.heibel@xxxxxxxxxxxxxx> wrote:
>> I wanted to bring up this discussion once more in order to finish it... ;)
>>
>> On Mon, Mar 15, 2010 at 4:10 AM, leon zadorin <leonleon77@xxxxxxxxx> wrote:
>>> On 3/14/10, Hauke Heibel <hauke.heibel@xxxxxxxxxxxxxx> wrote:
>>>
>>>> I thought it might be a good idea to remove the throw() declarations
>>>
>>> For as long as you retain your lib as 'header-only' one (i.e. no
>>> shared lib files) -- with using extern/global functions et al, the
>>> explicit "throw()" qualifier allows some compilers to optimize things
>>> that they otherwise would/could not...
>>>
>>> For instance, from:
>>> http://gcc.gnu.org/gcc-4.1/changes.html
>>> we have:
>>> "
>>> When generating code for a shared library, GCC now recognizes that
>>> global functions may be replaced when the program runs. Therefore, it
>>> is now more conservative in deducing information from the bodies of
>>> functions. For example, in this example:
>>>
>>>    void f() {}
>>>    void g() {
>>>     try { f(); }
>>>     catch (...) {
>>>       cout << "Exception";
>>>     }
>>>    }
>>>
>>> G++ would previously have optimized away the catch clause, since it
>>> would have concluded that f cannot throw exceptions. Because users may
>>> replace f with another function in the main body of the program, this
>>> optimization is unsafe, and is no longer performed. If you wish G++ to
>>> continue to optimize as before, you must add a throw() clause to the
>>> declaration of f to make clear that it does not throw exceptions.
>>> "
>>
>> So, does it mean we want to keep stuff or should we follow the advices
>> given by the boost devs and/or H. Sutter!?
>
> from the boost pple (in one of your links?):
> http://www.boost.org/development/requirements.html#Exception-specification
>
> "
> A non-inline function is the one place a "throws nothing"
> exception-specification may have some benefit with some compilers.
> "
>
> Which appears to resonate with the aforementioned quote from gcc ppl...
>
> So I'd say the issue is not always 100% one-way.
>
> But I am not against it either way -- esp. given that you guys are
> doing a great job in maintaining lib as a header-only one anyhow...
>
> On the general note I'd say it is rather difficult to get an
> all-agreed view from developers when talking to one camp or the other.
>
> For example, I recall talking to one of the boost people David A.
>
> (
> who had written
> http://www.boost.org/community/exception_safety.html
> )
>
> and his general views on the zero-overhead exceptions handling (when
> such are not thrown at least -- e.g. dwarf-related thingy in gcc).
>
> His strong opinion was that it is possible in most cases for the
> compiler to generate exception implementation which would, under the
> same semantics, exhibit no extra overhead w.r.t. error-checking
> mechanisms (when exceptions are not thrown at least).
>
> When a similar question was asked of the gcc developers (e.g.
> exception-handling implementation for example adversely affecting some
> of the otherwise-available optimizations the compiler could perform):
>
> http://readlist.com/lists/gcc.gnu.org/gcc-help/3/17092.html
>
> The answer was pretty much that the only way true zero-overhead (of
> non-throwing exceptions) that can be achieved is when compiler does
> not do optimizations.
>
> When I had relayed this response back to David, his reaction was that
> such statements are too generic and may be affected by other factors
> such as developers resources, their priorities for other
> compiler-developments and features etc. etc. etc., quote from his
> earlier email:
> "
> [...] It's easy to imagine that these optimizations also wouldn't be
> possible with any other error recovery mechanism that has the same
> semantics
> [...] there's nothing stopping a sufficiently intelligent compiler
> from making any semantics-preserving transformation it wants to,
> including replacing use of its EH mechanism with equivalent semantics
> using error codes. There's no "magic necessary penalty" for EH, but in
> practice its efficiency may be impaired by limited ability or
> cost/benefit considerations of compiler implementirs
> "
>
> So I think both camps are sort of right (some may have a greater
> insight in their specific compiler implementation and related issues,
> others may have a rock-solid awareness of what the implementation
> should be able to achieve)...
>
> I think you (i.e. non-compiler developers) would have no other option
> but to consider the current state of the compilers, their future
> direction of development and how this may impact you.
>
> Considering that you are header-only people, and advances made w.r.t.
> interprocedural optimisations (e.g. on the off-topic subject of
> '-fipa-sra' option in newer gcc, although I like more explicit
> boost-like callarg/param way at the moment) --
>
> -- I think that either way would be fine with me... :-) If you feel
> that benefits of throwing-out (pun intended :-) all
> exception-declarations (even the empty "throw()" ones) in prototypes
> outweigh the costs then go ahead :-)
>
> Kind regards
> Leon.
>
>
>
>> In case you insist of sticking to throw(), I can finally remove the
>> code I have in my repository.
>>
>> - Hauke
>>
>>
>>
>
>
>