Re: Exception Specification Compromise
On 8 Feb., 14:36, "Martin B." <0xCDCDC...@gmx.at> wrote:
DeMarcus wrote:
[snip]
Nevertheless, just because they're renowned C++ experts, that doesn't
stop me from proposing enhancements to their ideas.
So if the following holds:
* A no-throw function can, without functional harm, be declared throw()
since such function must throw nothing, compared to a throw( MyException
) that can throw more than just MyException due to templates.
If throw() is enforced during runtime - i.e. there is an implicit
catch(...)+handler added to each such function - this can have
performance implications depending on the platform.
I assume that you mean "depending on the compiler", not the platform.
And this is true, but then complain to the compiler writers or choose
a compiler where this overhead is not present.
If that holds, then I claim an optional feature in the compiler can, by
means of static checking during compile-time, help finding no-throw
functions that throws anyway. This optional feature would be no
disadvantage, but only an enhancement helping programmers writing
exception safe code.
Please give your comments on this.
I fully agree that some mechanism to statically enforce/analyse the
no-throw guarantee would be very welcome!
The problem is one of technology. With the linking model we use now,
it is impossible. And changing the model does not really change
anything.
Determining if a function can throw is to the best of my knowledge not
possible, and if it is, surely it will be computationally to expensive
to be usable.
Just take a simple function like:
std::vector<int> f()
{
std::vector<int> res(200000);
return res;
}
You can't determine if that function might throw unless you know what
new_handler is installed.
/Peter
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]