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:a05:620a:430c:: with SMTP id u12mr29277874qko.439.1632265737179; Tue, 21 Sep 2021 16:08:57 -0700 (PDT) X-Received: by 2002:a05:6902:124c:: with SMTP id t12mr39232847ybu.91.1632265737011; Tue, 21 Sep 2021 16:08:57 -0700 (PDT) Path: eternal-september.org!reader02.eternal-september.org!news.misty.com!border2.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: Tue, 21 Sep 2021 16:08:56 -0700 (PDT) In-Reply-To: Injection-Info: google-groups.googlegroups.com; posting-host=98.118.241.166; posting-account=QF6XPQoAAABce2NyPxxDAaKdAkN6RgAf NNTP-Posting-Host: 98.118.241.166 References: <9bc55d72-b90e-45c5-bfd8-cbce565d139dn@googlegroups.com> <44be7c73-f69e-45da-9916-b14a43a05ea3n@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <6a073ced-4c3b-4e87-8063-555a93a5c3f6n@googlegroups.com> Subject: Re: Custom Storage Pool questions From: Jere Injection-Date: Tue, 21 Sep 2021 23:08:57 +0000 Content-Type: text/plain; charset="UTF-8" Xref: reader02.eternal-september.org comp.lang.ada:62811 List-Id: I think the only thing that misses is scenarios where the compiler vendor isn't allocating a descriptor/bounds but is still using multiple allocations for the object. I don't know if that is a practical use, but it is one the RM allows? If so, it is probably more useful to know if a specific Allocate call is somehow a unique call relative to the others (the first call, the last call, etc.) so that the developer could earmark that one to be the one to add the custom header to. We can't change the Allocate specification since it is what it is, but is there any consideration to adding functionality to the root storage pool type, maybe a classwide function that lets the compiler developer set an internal flag for that unique allocation and a classwide function for the storage pool developer to see if that flag was set for the allocation. Or some other mechanism. It seems like this would need to be some sort of runtime mechanism if the multiple allocations can occur in the absence of needing a descriptor or bounds. Or maybe a generic version of the Storage_Pools package that allows a header type to be specified, that gives the compiler vendor some interface that easily facilitates allocating the header along side any object at the time and place the vendor finds convenient, and provides the custom storage pool implementer a means of knowing when that happens so they can initialize the header in the allocate function that creates it. I'm obviously not a compiler developer so I don't know the practicalness of any of that. But I think one root problem for a custom storage pool developer is "when is it safe to make a custom header for my object?". On Monday, September 20, 2021 at 8:50:41 PM UTC-4, Randy Brukardt wrote: > 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" <> wrote in message > news:44be7c73-f69e-45da...@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.