Re: Are throwing default constructors bad style, and if so, why?
Dave Harris wrote:
SeeWebsiteForEmail@erdani.org (Andrei Alexandrescu) wrote (abridged):
Au contraire, the fact that zombie state is the default-constructed
state makes it very easy to both attain and check. It only requires
careful writing of the destructor (it would be nicer still if the
compiler planted the appropriate code itself). Also, since all
member functions must check for the default-constructed state to
start with, they won't have any trouble in dealing with zombie
objects.
It sounds to me as though that approach permits resurrection. If default
construction produces a zombie, and first use initialises the object
properly, and destruction puts the object back into its default
constructed state, then a use after destruction would reinitialise it.
This strikes me as potentially bad. At best it conceals bugs. At worst
the resurrected object would not get destroyed a second time, and would
leak resources and have other problems (eg deadlocks due to locks not
getting released).
That's a great point, I'm glad you brought it up. This is not the design
I have in mind, so please let me explain mine on an example.
Consider a File type that provides the usual operations. Then say File
defines various iterators for input, output, parsing, the works. They
all "weakly" refer to the File. When File's destructor gets called, the
underlying file handle is closed, thus freeing the resource. The
iterators remain in a "defined but inoperable" state; any attempt to do
I/O through them will reproducibly throw an exception. But the File
object does not disappear! It only zeroes its internal file handle, such
that whenever an iterator tries to use it the closed state can be detected.
Can the file be reopened post destruction? Not via an iterator because
iterators can't manipulate the File. Could someone who has some pointer
to the original File open it again? Yes, but acquiring a resource must
be accompanied by an understanding of the ownership relationship in
vigor for that File. There could be none (the File was already
disowned), in which case the code that reopened it should acquire its
ownership. Not doing so would be a design mistake that indeed may lead
to problems. My point is that the resulting landscape makes it easier to
create correct designs. Allegedly :o).
In order to prevent resurrection the object needs to know the difference
between a new default-constructed object and a destroyed one. Code which
handles one case correctly won't necessarily handle both.
That's a good point. You have convinced me that at least some objects
would need a way to prevent resource re-acquisition after the destructor
was called. Alternatively, a resource wrapper's interface could be split
in two, one that acquires/release the resource, and one that uses the
resource but can't control its lifetime.
This is a very fertile subject. As an aside, I'm a bit surprised that
most people spend energy solely on rehashing the known problems with GC
+ destructors. Yes, it is understood there are problems. The more
interesting and challenging task is to define a system that does work.
Clearly it can't work exactly like today because the tradeoff space is
very different, but let's look for something that does work and presents
another, hopefully better but still different, tradeoff proposition.
Have you thought about the pImpl idiom? Any object can potentially be
implemented as a pImpl, in which case it needs memory for the Impl
whether or not it needs other resources.
[...]
Is this what you mean by good style? It strikes me as over-complex.
At this point I am not convinced whether all, or most, objects need to
enforce that meaningful use post-destruction is impossible. I'll
certainly need to think of it.
I especially dislike the need to use the "mutable" keyword. I'd be
tempted instead by code like:
int Wrapper::simpleAccessor() const {
return pImpl ? pImpl->simpleAccessor() : 0;
}
But this is a bit ad hoc and error-prone. (It is also an example of
checking for the default-constructed state but not for the destroyed
state.)
Well that's more of a problem with mutable. C++ hasn't gotten lazy
initialization quite right, and mutable is a bad palliative.
If instead we strength the class invariant by saying the Impl is always
allocated, the code gets much simpler and cleaner.
I agree in this case. But then again: in discussing the disadvantages of
an approach, don't forget the advantages.
Andrei
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]