From: Matthew Heaney <matthew_heaney@acm.org>
Subject: Re: Freeing Pointers to classwide types
Date: 1998/10/10
Date: 1998-10-10T00:00:00+00:00 [thread overview]
Message-ID: <m3r9whuzak.fsf@mheaney.ni.net> (raw)
In-Reply-To: 361E65A8.36082B5D@icon.fi
Niklas Holsti <nholsti@icon.fi> writes:
> Matthew Heaney wrote:
> [snip]
> > I like each specific type in the hierarchy to maintain its own free list
> > of already-allocated objects. Provide a class-wide operation that
> > dynamically dispatches a private Do_Free op. Something like:
> >
> > package P is
> >
> > type T is abstract null record;
> (* need "tagged" here)
> >
> > type T_Access is access all T'Class;
> > for T_Access'Storage_Size use 0;
> > --
> > -- By making this have a storage size of zero, you force
> > -- clients to call a constructor (allocator) for the specific
> > -- type.
>
> I don't see how the commented statement follows from the LRM text on
> the Storage_Size attribute. I'm looking mainly at LRM 3.11(18), which
> says that the actual size with be _at least_ the one specified, so
> even though you specify zero, the size could be a million units.
> In fact, the above code elicits the following message from GNAT:
> "Warning: implicit call of Initialize will raise Storage_Error."
>
> Could you explain how your suggestion works?
By specifying that the Storage_Size for an access type is 0, you're
effectively saying that the client isn't allowed to call allocator new.
If you call new for an access type whose storage size is 0, then you'll
get Storage_Error.
What I'm trying to do is remove any doubt that the way for a client to
allocate a new instance of (a descendent of) T is to call a constructor
for the specific type - under no circumstances is a client to call new
directly.
next prev parent reply other threads:[~1998-10-10 0:00 UTC|newest]
Thread overview: 61+ messages / expand[flat|nested] mbox.gz Atom feed top
1998-09-24 0:00 Freeing Pointers to classwide types joecool
1998-09-25 0:00 ` alan walkington
1998-09-25 0:00 ` Tom Moran
1998-09-25 0:00 ` Bob Fletcher
1998-09-25 0:00 ` dennison
1998-09-25 0:00 ` Samuel Tardieu
1998-10-09 0:00 ` Matthew Heaney
1998-10-12 0:00 ` Mats Weber
1998-10-12 0:00 ` Pat Rogers
1998-09-25 0:00 ` dewarr
1998-09-25 0:00 ` Tom Moran
1998-09-25 0:00 ` dewarr
1998-09-26 0:00 ` Tom Moran
1998-09-26 0:00 ` dewarr
1998-09-26 0:00 ` Tom Moran
1998-09-27 0:00 ` dewarr
1998-09-27 0:00 ` Tom Moran
1998-09-28 0:00 ` dewarr
1998-09-28 0:00 ` Tom Moran
1998-09-28 0:00 ` dewarr
1998-09-28 0:00 ` Tom Moran
1998-09-28 0:00 ` Pat Rogers
1998-09-28 0:00 ` Tom Moran
1998-09-28 0:00 ` Pat Rogers
1998-09-29 0:00 ` dewarr
1998-09-29 0:00 ` Tom Moran
1998-09-30 0:00 ` Tom Moran
1998-10-01 0:00 ` dewar
1998-10-01 0:00 ` Tom Moran
1998-10-01 0:00 ` dewarr
1998-10-01 0:00 ` dewarr
1998-10-01 0:00 ` Tom Moran
1998-10-01 0:00 ` Samuel Tardieu
1998-10-01 0:00 ` Tom Moran
1998-10-01 0:00 ` Tucker Taft
1998-10-01 0:00 ` Tom Moran
1998-10-02 0:00 ` dennison
1998-10-02 0:00 ` dewarr
1998-10-02 0:00 ` dewarr
1998-10-02 0:00 ` Larry Kilgallen
1998-10-02 0:00 ` dewarr
1998-10-01 0:00 ` dennison
1998-10-02 0:00 ` dewarr
1998-10-09 0:00 ` Matthew Heaney
1998-10-09 0:00 ` dennison
1998-10-09 0:00 ` Matthew Heaney
1998-09-28 0:00 ` Tom Moran
1998-09-28 0:00 ` Brian Rogoff
1998-09-28 0:00 ` dewarr
1998-09-28 0:00 ` Richard D Riehle
1998-09-28 0:00 ` Pat Rogers
1998-09-29 0:00 ` dewarr
1998-10-09 0:00 ` Matthew Heaney
1998-10-09 0:00 ` Matthew Heaney
1998-09-26 0:00 ` Simon Wright
1998-10-09 0:00 ` Matthew Heaney
1998-10-09 0:00 ` Niklas Holsti
1998-10-10 0:00 ` Matthew Heaney [this message]
1998-10-11 0:00 ` Niklas Holsti
1998-10-11 0:00 ` Matthew Heaney
-- strict thread matches above, loose matches on Subject: below --
1998-09-25 0:00 bpr5549
replies disabled
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox