Re: Are throwing default constructors bad style, and if so, why?
SeeWebsiteForEmail@erdani.org (Andrei Alexandrescu) wrote (abridged):
After destruction the object can't be accessed anyway.
Of course it can, via a dangling pointer. That is the problem.
But the behaviour isn't well-defined. Whatever state the destructor
leaves the object in, it can't legally be accessed and the compiler might
trash it anyway. (On my machine, the debug heap overwrites deleted bytes
with 0xdd.)
In a GC environment, there is an argument for using
dispose() instead, in order to get consistent
behaviour if the object is mistakenly accessed subsequently.
I am not so sure about that. "Subsequently" after what?
After we declare we have finished with it.
In a GC program, the programming model has it that all values
live forever.
I don't agree; even in GC an object has a lifetime that ends when its
destructor runs.
Why not make delete do dispose in a GC environment? (Not a
rhetorical question.)
That is too big a language change for me. GC should give the illusion of
infinite memory; it should not affect program semantics at all.
However, I'm fine with a function like destroy() which is mapped to
delete or dispose. The difference is the programmer is in control and
presumably has written her stuff accordingly.
The only extra thing you need to do is to write your destructor so
as to put the object in a defined state post destruction.
File::~File() {
if (!haendel) return;
fclose(haendel);
if (gc_in_action()) haendel = NULL;
}
What happens to virtual functions? If I have a pointer to an object of
type Derived, is it still a Derived after its destructor is run? Or is it
now a Base? Or just bytes?
In C++98 the object is left as just bytes. So the type system has a hole
in it whatever you try to do with haendel.
Yah, there is quite a lot of similarity. There is one other
difference: the destructor of a moved-from object will still be
called. A zombie will not have its destructor called.
I was talking about x.dispose(). A disposed object is in a destructible
state; it may be destroyed or it may conceptually live for ever.
-- Dave Harris, Nottingham, UK.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]