TEAM-ADA Archives

Team Ada: Ada Programming Language Advocacy


Options: Use Forum View

Use Monospaced Font
Show HTML Part by Default
Condense Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
"Team Ada: Ada Advocacy Issues (83 & 95)" <[log in to unmask]>
Sat, 9 May 1998 14:57:25 -0400
text/plain (34 lines)
> guarantee that *every* object creation
> causes one of my procedures to be called.
>    F : Final.Finis := (Controlled with null record);
>This bypasses the call to Initialize.
  You need an Adjust that increments the reference count, and
Create should not increment it.  A new object can come into
existence either with an Initialize call or (as above) with an
Adjust call, so both must be there and ready to increment the
reference count (or whatever).  Other functions which happen
to "return Final.Finis" (like Create in your example) should
not be fiddling with the reference count because they are not
creating or destroying objects - other than the creation or
destruction that is already accounted for by compiler
generated Initialize/Adjust/Finalize calls - they are merely
accessing existing objects.

>Ada 95 Initialize/Adjust/Finalize are not as flexible
>as C++ constructor/destructors because the have only
>to do with the *contents* of an object during its life
>*between* creation and deletion.  It would be nice to
>extend the programmer's control to permit activity at
>the endpoints of the object lifetime as well.
  Initialize/Adjust/Finalize are called by the compiler
exactly at the endpoints of existence.  I don't understand
what you might mean by accessing the object before it is
created or after it is deleted.

  BTW, this has apparently been difficult for compiler
writers, too.  If you are making test programs make sure you
have a compiler that's doing the correct thing.  There have
been problems in the past.