Re: Exception in the constructor can't be caught?
On Aug 1, 5:25 pm, blargg....@gishpuppy.com (blargg) wrote:
In article
<ef422ec9-84d3-4185-9034-752b62d1b...@a1g2000hsb.googlegroups.com>, James
Kanze <james.ka...@gmail.com> wrote:
On Jul 31, 8:33 pm, Fred <fred.l.kleinschm...@boeing.com> wrote:
On Jul 31, 10:59 am, Christian Hackl <ha...@sbox.tugraz.at> wrote:
[...]
here:http://www.gotw.ca/gotw/066.htm
Interesting that the article contains these statements:
Q: When does an object's lifetime end?
A: When its destructor begins. That is, control reaches
the beginning of the destructor body.
I disagree with the above.
...
The object MUST exist until the final statement of the
destructor is executed.
The underlying raw memory must exsit, and the sub-objects must
exist, but the object itself, no.
It sounds like you're saying that this yields undefined
behavior:
struct S
{
virtual void f() { cout << typeid (*this).name(); }
void g() { f(); }
virtual ~S() { g(); }
};
int main() { S s; }
Now where did I say that?
How could the S object's lifetime have ended, yet virtual
functions still work?
Because the standard says that they do. That's really the only
answer I can give. The standard says that for everything
concerning RTTI (dynamic_cast, typeid and virtual function call
resolution), the "object" (whose lifetime has ended) acts as if
it had the type of the destructor being executed.
I obviously need to re-read relevant sections of the standard,
but I'm sure I'm not the only one who finds the above
statements surprising, even if my example program doesn't
yield any undefined behavior.
I'll admit that the standard's wording isn't always the most
intuitive. I think the problem is that it is trying to use a
binary state (alive/dead) for a situation that isn't binary.
The object's "lifetime" starts when the most derived constructor
is finished, and ends when the most derived destructor starts
(see =A73.8), but a not yet alive object (or an already dead
object) definitely has certain properties of the object (and not
of just raw memory). Section 3.8 basically says that there are
only a limited set of things that you can do outside of the
lifetime, but in practice, some of them just don't make sense:
according to =A73.8, for example, you can't convert a a pointer to
the object to a pointer to the base class. Which taken
literally would mean that you can't call a member function of a
base class from the constructor, because that implies an
implicit conversion of the this pointer to a pointer to the base
class. Note, however, that there are special rules which are in
effect in constructors and destructors, and that some things
that seem like the obviously should work are actually undefined
behavior (and in one case I had, didn't work).
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34