Re: RE>Re- Constructor bombs f

[Michael McClary <michael>]

> Waddaya think?  How about having NULL member initializers generated
> from the translator?  (For CHKPTRs, NULL initialization already happens
> implicitly.)  Michael, please be gentle {-%

It all looks very good to me (Even though I haven't had breakfast yet.  B-).
Especially the trailing px=NULL;  Thanks to you both.  Several comments:

 1) Yes, the PLANT_CONSTRUCTOR_BOMB(); is very important.  Without it,
    the destructors are never called, and all of this exercise is wasted.

 2) Note that:

	Foo::
	Foo()
		: pz(NULL)
		, px(NULL)
	{
		PLANT_CONSTRUCTOR_BOMB();
	...

    and:

	Foo::
	Foo()
	{
		PLANT_CONSTRUCTOR_BOMB();
		pz = NULL;
		px = NULL;
	...

    Are exactly equivalent (except that in the first case pz and
    px will be stored in the order that they were declared in the
    class definition, assuming 2.0 and 2.1 do it the same way).

 3) When using a CONSTRUCTOR_BOMB in a constructor with initializers
    you must be VERY careful not to do anything that might blast
    in the initialization section, because a blast out of there
    will cause parts of the initialization to be skipped, but the
    destructor will assume that it was all done.  For instance:

	Foo::
	Foo()
		: pz(NULL)
		, px(NULL)
		, pw(foe + fum())
	{
		PLANT_CONSTRUCTOR_BOMB();
	...

    is hazardous, because if fum() fails, the destructor may be
    called with px and/or pz containing heap-junk rather than
    NULL.  (Remember that pw = fum() might happen before
    px = NULL; or pz = NULL because of initializer re-ordering.)

By the way, the trend of this discussion makes me feel much better
about the maintainibility of our code.  We seem to be converging
on a style within the set I consider "right" solutions.

	michael