Re: Are throwing default constructors bad style, and if so, why?
Dave Harris wrote:
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.)
Right. That's exactly why I'm advocating against releasing value's
memory after destruction and putting it in a specific state (the actual
state at this moment is unclear).
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.
But this is exactly the contradiction we're trying to assuage. We're
trying to define a behavior with GC+destructors, not to assume what it is.
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.
Alright. The crucial question is now, what state does destroy() put the
object in, and what should that state allow and disallow?
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?
Good question. Ideally it would be a "bottom" vptr that only points to
functions that throw.
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. I think that needs fixing if C++ is to be used effectively with GC.
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.
That sounds about right. But, a disposed object, can it allocate
resources again?
Andrei
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]