Re: Exception Specification Compromise
On 10 Feb., 07:35, DeMarcus <use_my_alias_h...@hotmail.com> wrote:
Seungbeom Kim wrote:
DeMarcus wrote:
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.
[snip]
Just to not diverge from the original thread I want to emphasize that
the idea is to track no-throw functions only. [...]
[...]
* If a function is declared throw() it is a no-throw function. If it is
not declared throw() it may throw whatever, according to the compiler.
* If a throw()-declared function contains any function that is not
declared throw(), we get a warning.
I'm afraid you don't seem to understand. Take the following function
for example:
std::vector<int> f() throw()
{
std::vector<int> res(200000);
return res;
}
Peter's argument was that it was impossible for the compiler to
determine whether a function (like the one above) might throw.
How should your optional compiler feature respond to this?
Maybe I miss something, but wouldn't the compiler be able to see that
std::vector's constructor is declared without throw()?
Exactly. This is because it can throw (when instantiated with an int)
an out of memory exception. But if we install a new_handler that
terminates the process when called, the above function will never
throw and would thus be a safe function.
The std::vector's constructor is not declared throw(), hence the
compiler can easily see that f() might throw, or actually crash since
f() is declared throw() which will stop all exceptions. In your example
the compiler would give a warning that f() is declared no-throw but
calls functions not declared no-throw.
And such warnings would abound - for how many functions can you really
call that will never throw. The example above was slightly contrived,
but there are lots of cases where the function will not be declared
throw() but the call wont throw. This could be because the parameters
are checked, because the original author did not use an empty
exception specification or because the author could not use an empty
exception specification e.g because the function is a template.
However, something that I don't know is the following.
std::vector<int> f() throw()
{
try
{
std::vector<int> res(200000);
return res;
}
catch(...) {}
}
Will the copy to the return value be embraced by the try/catch(...)?
I don't know. Does anyone know?
The code above will not return anything: you need to put something in
the catch clause.
One thing I know though, is that no-throw operations should not return
values that must use a copy constructor (see Exceptional C++ by Herb
Sutter, Item 10). That is why pop_back() never returns the popped value.
That depends entirely on the copy-constructor.
I mean, already here we see the effect of the static check. If someone,
from a no-throw function, returns a value that uses the copy constructor
we will get a warning.
No.
/Peter
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]