From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID
	autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,ed6a891101ff4e06
X-Google-Attributes: gid103376,public
From: Matthew Heaney <matthew_heaney@acm.org>
Subject: Re: Freeing Pointers to classwide types
Date: 1998/10/10
Message-ID: <m3r9whuzak.fsf@mheaney.ni.net>#1/1
X-Deja-AN: 399603114
Sender: matt@mheaney.ni.net
References: <1ftmFTC69GA.191@samson.airnet.net>
 <m3r9wjvt6c.fsf@mheaney.ni.net> <361E65A8.36082B5D@icon.fi>
NNTP-Posting-Date: Fri, 09 Oct 1998 22:42:22 PDT
Newsgroups: comp.lang.ada
Date: 1998-10-10T00:00:00+00:00
List-Id: <comp.lang.ada>

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.