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=-0.9 required=3.0 tests=BAYES_00,XPRIO autolearn=no
	autolearn_force=no version=3.4.6
Path: eternal-september.org!reader02.eternal-september.org!gandalf.srv.welterde.de!news.jacob-sparre.dk!franka.jacob-sparre.dk!pnx.dk!.POSTED.rrsoftware.com!not-for-mail
From: "Randy Brukardt" <randy@rrsoftware.com>
Newsgroups: comp.lang.ada
Subject: Re: Custom Storage Pool questions
Date: Mon, 20 Sep 2021 19:50:38 -0500
Organization: JSA Research & Innovation
Message-ID: <siba8v$nvh$1@franka.jacob-sparre.dk>
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>
Injection-Date: Tue, 21 Sep 2021 00:50:39 -0000 (UTC)
Injection-Info: franka.jacob-sparre.dk; posting-host="rrsoftware.com:24.196.82.226";
	logging-data="24561"; mail-complaints-to="news@jacob-sparre.dk"
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 6.00.2900.5931
X-RFC2646: Format=Flowed; Original
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.7246
Xref: reader02.eternal-september.org comp.lang.ada:62800
List-Id: <comp.lang.ada>

A better solution would be to know the size of those bounds objects and 
treat them differently (I've done that). And the next allocation is going to 
be the data, so I don't do anything special for them. Probably would be nice 
to have an attribute for that. But no one has ever asked for any such thing, 
so I haven't defined anything.

Such pools are highly implementation specific, so I haven't worried about 
this much..

                            Randy.

"Emmanuel Briot" <briot.emmanuel@gmail.com> wrote in message 
news:44be7c73-f69e-45da-9916-b14a43a05ea3n@googlegroups.com...
>> > 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.