In article <mcclaryD3M69A.I9G@netcom.com>,
Michael McClary <mcclary@netcom.com> wrote:
>In article <D3FHH1.1us@cix.compulink.co.uk>,
>R Cox Zergo Ltd <richardcox@cix.compulink.co.uk> wrote:
>
>>ARM Section 15.3 "Constructors and Destructors"
>
>I'd like to see the following clarifications:
>
> A: "An Object that is partially constructed will have destructors
>     executed only for its fully constructed sub-objects".

 AFAIK it is done in the Working Paper.

> An object being constructed via a constructor with a non-null body
> is considered "fully constructed", and will have its destructor
> called, once execution of the code within the constructor's curly
> braces has BEGUN.

Nope. Only when the body completes execution. Think about it.

BTW: reversing the order of destruction of bases is non-trivial
and may cost. Think about virtual bases: the currently executing
constructor _cannot_ reverse the order, only the most derived
class knows the order.
--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,
        81A Glebe Point Rd, GLEBE   Mem: SA IT/9/22,SC22/WG21
        NSW 2037, AUSTRALIA     Phone: 61-2-566-2189

In article <D3FHH1.1us@cix.compulink.co.uk>,
R Cox Zergo Ltd <richardcox@cix.compulink.co.uk> wrote:

>ARM Section 15.3 "Constructors and Destructors"

>"As control, passes from a throw-point to a handler, destructors are
>invoked for all automatic objects constructed since the try-block was
>entered.
>  An Object that is partially constructed will have destructors executed
>only for its fully constructed sub-objects".
>
>Need I say more?

You don't, but the ARM should.

I'd like to see the following clarifications:

 A: "An Object that is partially constructed will have destructors
     executed only for its fully constructed sub-objects".

 Within this context, a sub-object is:
  - a base class
  - a non-static member variable of class type
  - an element of a non-static member array of objects of class type
  - sub-objects of sub-objects.

 An object being constructed via a constructor with a non-null body
 is considered "fully constructed", and will have its destructor
 called, once execution of the code within the constructor's curly
 braces has BEGUN. (1)  The destructor will be called after any
 remaining automatic objects in the constructor's scope have been
 destroyed.  (2)

(1) is a deviation from the obvious reading of A.  It allows destrutors of
objects with non-trivial construction to execute, determining the extent
of the constructor's progress (i.e. by examining member variables) and
gracefully unwinding it.  Doing otherwise limits the complexity of
construction to what can be done on an all-or-nothing basis, encouraging
workarounds composed of extra levels inheritance and protected variables
at the cost of clarity.

(2) follows from (1) and the requirement that destruction be done in the
reverse order of construction:  The non-destroyed state of the automatic
objects in the constructor may represent global side-effects that their
destructors will unwind.  They must be destroyed to complete the cleanup
of the partially-executed constructor before the destructor can execute.

--
 (My usual signature suppressed since it's not germane to this group.)

Michael McClary      mcclary@netcom.com
For faster response, address electronic mail to: michael@node.com

mcclary@netcom.com (Michael McClary) wrote:

> An object being constructed via a constructor with a non-null body
> is considered "fully constructed", and will have its destructor
> called, once execution of the code within the constructor's curly
> braces has BEGUN. (1)
>
>(1) is a deviation from the obvious reading of A.  It allows destrutors
of
>objects with non-trivial construction to execute, determining the extent
>of the constructor's progress (i.e. by examining member variables) and
>gracefully unwinding it.  Doing otherwise limits the complexity of
>construction to what can be done on an all-or-nothing basis, encouraging
>workarounds composed of extra levels inheritance and protected variables
>at the cost of clarity.

I'm sure that others will respond, but I feel compelled to make my
response.  I've been working on a project for two years now that assumes
objects are not fully constructed until the constructor completes
execution.  Changing the rule now would require significant changes to my
project's code base.  What's more, with two years experience behind me, I
see no reason to change the rule.  In the few cases where a constructor is
"non-trivial", I have found that using try blocks within the constructor
to be quite sufficient to correctly unwind the side-effects of the partial
construction.

Jim Lloyd
afcjlloyd@aol.com -or- Jim_Lloyd@powertalk.apple.com