Re: [eigen] exception specifications...

[leon zadorin <leonleon77@xxxxxxxxx>]

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
>
>
>