Re: Are throwing default constructors bad style, and if so, why?
SeeWebsiteForEmail@erdani.org (Andrei Alexandrescu) wrote (abridged):
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).
Again, why bother? Wouldn't it be simpler not to destroy the object in
the first place?
It seem to me that there are two choices for what to do with an object
you've finished with:
(1) Dispose it, ie put it into a well-defined (at language level) zombie
state. The application is responsible for trapping any uses of that state.
It can pick a balance between convenience for clients, performance and
reproducibility, depending on circumstances. I think it makes sense to
suggest some guidelines here, and maybe identify some good patterns, but
there probably aren't universal hard rules. GC helps the programmer by
providing the illusion of unbounded memory.
(2) Destruct it. Any further use of the object is undefined behaviour.
The language implementation gets to make the trade-off between
performance and reproducibility, as configured by command-line parameters
and such. GC helps the compiler by preventing the memory from being
reused and accidentally put into a non-trapping state.
You seem to be advocating (1), but it's not clear to me that the
programmer can do a better job than the compiler. Quite the reverse.
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.
I've not seen a good reason to change what we already have. GC gives us
the opportunity to use dispose instead of delete; I see no reason to
change what delete means. If delete doesn't do what you want, don't use
it; use dispose instead.
If we change GC delete by making what was undefined behaviour,
well-defined, then we (a) hamper the implementation's ability to enforce
its own safeguards; and (b) create a compatibility gap between GC and
non-GC platforms.
(b) is a serious issue. I don't want GC to balkanise the C++ landscape.
We should be seeking ways to write code that is correct if GC is absent,
and takes maximal advantage of GC if it is present.
Ideally it would be a "bottom" vptr that only points
to functions that throw.
On typical desktop machines the vptr can be set to NULL or a similar bad
address. Then any attempt to use it results in a hardware address fault.
(This is already done by, eg, Microsoft's VC++; GC doesn't require
anything new here.)
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.
I am happy to leave it as a hole. Especially as implementations are good
at catching consequent problems. They could be better, and GC will help
them be better; this is something to lobby compiler vendors about.
But, a disposed object, can it allocate resources again?
That's up to the object.
As a rule of thumb I should think it was OK provided the dispose and
resurrection steps are explicit, as with a file that can be closed and
then re-opened (with a different filename). In practice it's often better
to create a new file object for the second filename. However, sometimes
it's more convenient to reuse an existing object and this can be done
safely. The idea here is that dispose() is being used, not as a
substitute for delete, but as a general programming idiom that would make
sense whether or not GC is present.
-- Dave Harris, Nottingham, UK.
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]