Re: Are throwing default constructors bad style, and if so, why?

Thanks to all who responded to my inquiry. There's been a great deal of
insightful answers and examples given, such as:

1. Mutex initialization. It turns out that only initialization (not
acquisition!) of a mutex could fail. For example pthread_mutex_init
could fail (see
http://opengroup.org/onlinepubs/007908775/xsh/pthread_mutex_init.html).
Interestingly, InitializeCriticalSection returns void (see
http://msdn.microsoft.com/en-us/library/ms683472(VS.85).aspx) but may
fail by throwing a structured exception on pre-Vista Windae.

2. An image buffer would require dynamic allocation in its constructor
for proper functioning, which might fail.

3. More generally, objects of which state depends on globals and
singletons might as well throw an exception in their default constructor.

Along the way, considerations regarding "moved-from" states, two-stage
construction (blech), and lazy initialization were made. Neat.

I asked the question because I'm coming from a slightly unusual angle.
I've been using a garbage-collected environment for a while. When a GC
is in the equation *together* with deterministic destruction,
Interesting Things(TM) happen. One of them is that it's a great idea to
separate teardown (destruction) from deallocation. For example:

Foo * p = new Foo(...);
....
delete p;

In a GC environment, it makes a lot of sense if the delete statement
only invokes Foo's destructor against *p and then... leaves the object
alone in a "valid but non-resource-consuming" state.

Such an approach is not foreign to many on this group; there's been many
a discussion about what was descriptively called "zombie" object states.

The advantage of separating teardown from deallocation is that there are
no more dangling pointers, and consequently even incorrect programs
could achieve predictable, reproducible, and consequently debuggable
behavior. That way you get to use GC for what it's best at (recycling
memory) and deterministic teardown for what it's best at (timely release
of resources). In fact I'd go as far as saying that I think separating
teardown from deallocation an essential ingredient in successfully
marrying deterministic teardown with garbage collection. Other schemes
could be conceived, and I've thought of a few, but at least those I
could imagine lead to a m?salliance at most.

Once we accept the reality of "destroyed but not deallocated" objects,
we need to define that state appropriately. That state claims no more
resources than the bits of Foo alone, and must be detected by all member
functions of the object such that they have defined behavior for that state.

A genuinely distinct state could be defined. A reasonable decision is to
define that state as the default constructed state. Such a decision may
not always be perfect, but it has some advantages:

a) For many types, the default constructor does construct an impersonal,
empty, aloof object that does no more than compare equal to all other
default-constructed objects. Save for collecting information from the
environment, a default-constructed object does not have any
parameterization to make it "different".

b) All member functions need to take care of the "zombie" state anyway,
and often they also need to take care of the default-constructed state,
so merging the two can simplify things.

c) The rule is easy to explain and remember. Introducing a new zombie
state defined on a per-case basis only further adds to the complications
of defining types.

d) Non-throwing default constructors occasionally facilitate writing
algorithms. For example, in Hoare's partition it's convenient to store
the pivot in a local temporary. The temporary is default-constructed and
then only swapped around. In other words, non-throwing default
constructors allow writing "conservative" algorithms on collections that
do not create any new value, but do use temporary memory to shuffle
values around.

There are disadvantages too, for example it becomes impossible to
distinguish a legit default-constructed object from one that has had a
life and kicked the bucket. For example in the mutex case it may make
sense to define a default-constructed mutex one on which initialization
did succeed, and a zombie one a mutex that is obliterated with an
illegal bit pattern. (A more portable solution would need to add a bool
to the object state.)

I'd be interesting in hearing further opinions on how garbage collection
interacts with defining object states.

Andrei

--
      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated. First time posters: Do this! ]