Re: abstract sub programs overriding

["Randy Brukardt" <randy@rrsoftware.com>]

"Hyman Rosen" <hyrosen@mail.com> wrote in message
news:1079622255.263633@master.nyc.kbcfp.com...
> Randy Brukardt wrote:
> >>What you as an author want is that any object that is correctly
> >>initialized will be finalized, that any object which is not initialized
> >>will not be finalized, and there are no objects in the middle.
> >
> > Right, but that's a tough property to guarentee, particularly if you
want to
> > to be reasonably secure from abort and the like.
>
> C++ does its best to guarantee this, but will abort the program if,
> during the automatic destruction of objects as a result of a thrown
> exception, another exception propagates out of one of these destructors.
> There's only so much you can do in cases like that. Even Ada raises a
> program error in such cases.

I was thinking about task abort, which can leave stuff in pretty much any
state. You can protect against exceptions, but you can't protect against
abort. (With two important exceptions: protected operations and
Initialize/Adjust/Finalize routines are abort-deferred.)

> But if you write your destructors so that exceptions can never escape
> (which is the recommended style, because throwing an exception out of
> a function "means" that the function cannot fulfill its duty, whereas
> a destructor has no choice in the matter, since the object is being
> destroyed regardless of what the destructor thinks about it), then C++
> provides that guarantee - objects are constructed once and any object
> which is constructed will be destructed. (Barring manual intervention,
> of course.)

I think that is true in Ada as well. The question that Robert Eachus is
thinking about is what happens if an Initialize routine propagates an
exception (or a constructor in C++). In such a case, the object could be
partially initialized. Ada says that the top-level finalizer will not be
called in that case (although the finalize of controlled components that
completed initialization will be called).

This also covers abort during initialization (before Initialize is called,
since it is abort-deferred). But abort of an assignment can cause an object
to end up in a goofy state (say, if it happens between the target
finalization and the Adjust).

>  > I think it is best to depend primarily of a valid flag
>
> The problem with a valid flag is that it pushes the responsibility for
> validity testing out to all the methods. One of the goals of having a
> constructor in OO was to localize object construction in one place, so
> every other method could assume that the object was in a consistent and
> valid state.

Not necessarily. What I was thinking of was a flag for the use of
Initialize/Adjust/Finalize -- so that Finalize does nothing if it is not
set. That's absoletely necessary if you use Robert's aggregate assignment,
because Finalize will be called with an object on which Initialize has not
run. And it's always possible in the Ada model that Finalize will be called
twice. OTOH, any (other) method of the type can assume that the object is
valid. (This presumes that Initialize isn't calling methods, but that is
under the control of the programmer.)

> > (For someone who claims to not know Ada very well, Hyman knows Ada very
>  > well. He should join the ARG. :-) We could use him.)
>
> :-) It's mostly that I understand in pretty excruciating detail how
> things work in C++ (and in Java, to some extent), and the reasons for
> those behaviors. When I see that Ada does something differently, I can
> try to figure out whether those reasons will have an effect that C++
> was designed to avoid. (Note that I'm not claiming C++ is better, I'm
> just comparing effects of different decisions.)

Which was my point. Many ARG members don't know C++ that well, so we may
miss subtilies of the design. Your input is very useful that way. It would
be especially useful on the new features of Ada 2005 (like interfaces),
while we still can repair screw-ups.

                 Randy.