comp.lang.ada
 help / color / mirror / Atom feed
From: eachus@spectre.mitre.org (Robert I. Eachus)
Subject: Re: Destructor question
Date: 1998/12/08
Date: 1998-12-08T00:00:00+00:00	[thread overview]
Message-ID: <EACHUS.98Dec8112427@spectre.mitre.org> (raw)
In-Reply-To: m3k90559po.fsf@mheaney.ni.net

In article <m3k90559po.fsf@mheaney.ni.net> Matthew Heaney <matthew_heaney@acm.org> writes:

  > An alternative implementation uses a (private) subprogram that takes an
  > access parameter:

  >    procedure Do_Deallocate (The_Object : access Object);

  > This of course dispatches on the tag of The_Object.  It more-or-less
  > combines the two parameters of Bob's solution into one parameter.

    This is essentially a style issue, but for didactic purposes, I
wanted to avoid the clash between access parameters and
Unchecked_Deallocation.  Matt's example deals with this correctly, but
it is probably more difficult for someone learning Ada to understand.


  > I prefer to instantiate Unchecked_Deallocation using a specific
  > type, rather than a class-wide one.

    I understand, I think, what Matt meant to say here from context,
but it is tough to put in correct words.  "I prefer to instantiate
Unchecked_Deallocation where neither the object type nor the
designated type in the formal access parameter is classwide," may be
more correct, but it is certainly much harder on the eyes. The
difference between Matt's implementation and mine here is in the type
designated by the access type, and I just chose to use the one in the
original example.  However, I strongly agree that you do not want to
instantiate Unchecked_Deallocation with a classwide object type.
Language lawyers can argue about when this is required to work by the
RM but allowed just to not collect the storage (or just do a lot of
otherwise unnecessary checking) and when it is allowed to erroneusly
collect the wrong amount of storage, but you are much better off not
putting the gun to the implementors head.

   (The problem is that if you instantiate using a classwide type, the
compiler won't know when the sizes of the objects of a given subtype
are static, and when thunks or some other dynamic method is necessary
to determine the amount of space to free.  So a "correct"
implementation will potentially require creating thunks for all
possible target subtypes.  If you instantiate for a specific type,
even if it is inside a dispatching operation, then the compiler can
generate decent code for each instance.  Of course, the implementation
of the standard storage pool may include a size in each object, but
that doesn't help with user defined pools.)

--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...




  reply	other threads:[~1998-12-08  0:00 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1998-12-02  0:00 Destructor question Rusnak
1998-12-03  0:00 ` Jeff Carter
1998-12-03  0:00   ` Rusnak
1998-12-04  0:00     ` Robert I. Eachus
1998-12-06  0:00       ` Matthew Heaney
1998-12-08  0:00         ` Robert I. Eachus [this message]
1998-12-06  0:00     ` Matthew Heaney
1998-12-07  0:00     ` Jeff Carter
1998-12-06  0:00 ` david.c.hoos.sr
1998-12-06  0:00   ` Matthew Heaney
1998-12-08  0:00   ` Robert I. Eachus
1998-12-06  0:00 ` Matthew Heaney
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox