Re: How expensive are exceptions? =?utf-8?B?w4PDkMOAw4bDhMOAw40=?= =?utf-8?B?w4UhIMOCw4DDmMOAIMOBw4XDkcOPw4XDl8ONw47DkcOSw5wgw43DgCDDkMOT?= =?utf-8?B?w4rDkyDDgsOOw5DDgMOMIQ==?=
on Wed Jun 13 2007, "Sergey P. Derevyago" <non-existent-AT-iobox.com> wrote:
David Abrahams wrote:
I agree that it's true,
Good :)
but it's totally irrelevant.
No, it's not.
The same applies to any simple recursive function (or any function
that may eventually appear twice in the same call stack):
No. At least not in this sense.
Look, (roughly speaking) the unwinding runtime deals with one stack
frame
at a time:
1. In the case of recursive function one stack frame together with
some PC
value points to known number of objects to be destructed.
2. But in the case of array construction one stack frame+PC points
to
_unknown_ number of objects!
OK, for the last time, and then I'm done: the number of objects is not
unknown. It's known at runtime and represented in an implicit
automatic variable. The issues are no different from the issues in
this case, where there is no array.
void f()
{
for (int i = 0; i < 10; ++i)
{
try
{
c(i); // might throw
}
catch(...)
{
while (i > 0)
d(--i);
throw;
}
}
}
Each call to c corresponds to an element construction in the array
case. Each call to d corresponds to an element destruction in the
array case. The value of i needs to be available in order to do the
recovery (just as it would be if some mechanism other than EH was
being used to do error handling). The compiler internally translates
array construction to something very much like the above. The issues
are the same.
There's no magic here.
--
Dave Abrahams
Boost Consulting
http://www.boost-consulting.com
The Astoria Seminar ==> http://www.astoriaseminar.com
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]