From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on
	ip-172-31-74-118.ec2.internal
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00,FREEMAIL_FROM
	autolearn=ham autolearn_force=no version=3.4.6
X-Received: by 2002:ac8:4308:: with SMTP id z8mr14070762qtm.121.1632157152174; Mon, 20 Sep 2021 09:59:12 -0700 (PDT)
X-Received: by 2002:a25:3086:: with SMTP id w128mr33723314ybw.139.1632157152035; Mon, 20 Sep 2021 09:59:12 -0700 (PDT)
Path: eternal-september.org!reader02.eternal-september.org!news.uzoreto.com!tr3.eu1.usenetexpress.com!feeder.usenetexpress.com!tr3.iad1.usenetexpress.com!border1.nntp.dca1.giganews.com!nntp.giganews.com!news-out.google.com!nntp.google.com!postnews.google.com!google-groups.googlegroups.com!not-for-mail
Newsgroups: comp.lang.ada
Date: Mon, 20 Sep 2021 09:59:11 -0700 (PDT)
In-Reply-To: <44be7c73-f69e-45da-9916-b14a43a05ea3n@googlegroups.com>
Injection-Info: google-groups.googlegroups.com; posting-host=146.5.2.231; posting-account=lJ3JNwoAAAAQfH3VV9vttJLkThaxtTfC
NNTP-Posting-Host: 146.5.2.231
References: <e3c5c553-4a7f-408a-aaa7-60ec0b70202dn@googlegroups.com> <shmnk1$lgf$1@franka.jacob-sparre.dk> <9bc55d72-b90e-45c5-bfd8-cbce565d139dn@googlegroups.com> <iqqoc7F2lr8U1@mid.individual.net> <44be7c73-f69e-45da-9916-b14a43a05ea3n@googlegroups.com>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <418724ab-d9a8-43d8-ad72-dc9c4b2daf31n@googlegroups.com>
Subject: Re: Custom Storage Pool questions
From: Shark8 <onewingedshark@gmail.com>
Injection-Date: Mon, 20 Sep 2021 16:59:12 +0000
Content-Type: text/plain; charset="UTF-8"
Xref: reader02.eternal-september.org comp.lang.ada:62788
List-Id: <comp.lang.ada>

On Monday, September 20, 2021 at 12:48:21 AM UTC-6, briot.e wrote:
> > > If a compiler is allowed to break up an allocation into multiple 
> > > calls to Allocate (and of course Deallocate), how does one go about 
> > > enforcing that the user's header is only created once? 
> > I think one cannot enforce that, because the calls to Allocate do not 
> > indicate (with parameters) which set of calls concern the same object 
> > allocation.
> I think the only solution would be for this compiler to have another attribute similar to 'Storage_Pool, but that would define the pool for the descriptor: 
> 
> for X'Storage_Pool use Pool; 
> for X'Descriptor_Storage_Pool use Other_Pool; 
> 
> That way the user can decide when to add (or not) extra headers.
Hmmm, smells like a place to use generics and subpools; perhaps something like:

Generic
   Type Element(<>) is limited private;
   Type Descriptor(<>) is limited private;
   with Create( Item : Element ) return Descriptor;
Package Descriptor_Subpool is
   Type Pool_Type is new System.Storage_Pools.Subpools.Root_Storage_Pool_With_Subpools with private;
Private
   -- Element-subpool & descriptor-subpool defined here.
   -- Allocation of element also allocates Descriptor.
End Descriptor_Subpool;

Just top-of-the-head musings though.