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:ad4:40d1:: with SMTP id x17mr2689400qvp.7.1631581487781; Mon, 13 Sep 2021 18:04:47 -0700 (PDT) X-Received: by 2002:a25:4f8a:: with SMTP id d132mr18306877ybb.486.1631581487542; Mon, 13 Sep 2021 18:04:47 -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: Mon, 13 Sep 2021 18:04:47 -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: User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <036086ba-ea40-44cb-beb7-cded0f501cfbn@googlegroups.com> Subject: Re: Custom Storage Pool questions From: Jere Injection-Date: Tue, 14 Sep 2021 01:04:47 +0000 Content-Type: text/plain; charset="UTF-8" Xref: reader02.eternal-september.org comp.lang.ada:62728 List-Id: On Monday, September 13, 2021 at 1:29:39 AM UTC-4, Randy Brukardt wrote: > Not sure what you are expecting. There is no requirement that objects are > allocated contigiously. Indeed, Janus/Ada will call Allocate as many times > as needed for each object; for instance, unconstrained arrays are in two > parts (descriptor and data area). > No expectations. Just questions. I wasn't concerned with whether the allocated memory was contiguous or not, but whether an implementation is required to supply the correct size of memory needed to allocate an object or if it is allowed to pass a value to Size that is less than the amount of memory actually needed. For example, the blog there indicates the maintainer of the custom storage pool needs to account for First/Last indexes of an unconstrained array separately instead of assuming that value is included as part of the Size parameter's value. If the Size parameter doesn't require that it includes space for First/Last for unconstrained arrays or Prev/Next for controlled objects (assuming that is even the implementation picked of course), then I'm not seeing a way to write a custom storage pool that is portable because you need to account for each implementation's "hidden" values that are not represented in the Size parameter. For example if Janus calculated Size to have both the size of the array and the size of First and Last but GNAT didn't and my storage pool assumed the JANUS method, then if someone used my storage pool with GNAT then it would access memory from some other location potentially and erroneously. > The only thing that you can assume in a portable library is that you get > called the same number of times and sizes/alignment for Allocate and > Deallocate; there's no assumptions about size or alignment that you can > make. So to be clear, you cannot assume that Size and Alignment are appropriate for the actual object being allocated correct? Size could actually be less than the actual amount of memory needed and the alignment may only apply to part of the object being allocated, not the full object? Is that correct? I'm asking because that is what the blog suggests with the example it gave. > > If you want to build a pool around some specific allocated size, then if it > needs to be portable, (A) you have to calculate the allocated size, and (B) > you have to have a mechanism for what to do if some other size is requested. > (Allocate a whole block for smaller sizes, fall back to built-in heap for > too large is what I usually do). > Are there any good tricks to handle this? For example, if I design a storage pool around constructing a particular type of object, what is normally done to discourage another programmer from using the pool with an entirely different type? Maybe raise an exception if the size isn't exact? I'm not sure what else, unless maybe there is an Aspect/Attribute that can be set to ensure only a specific type of object can be constructed. HISTORY: > > > > "Jere" <> wrote in message > news:e3c5c553-4a7f-408a...@googlegroups.com... > >I was learning about making user defined storage pools when > > I came across an article that made me pause and wonder how > > portable storage pools actually can be. In particular, I assumed > > that the Size_In_Storage_Elements parameter in the Allocate > > operation actually indicated the total number of storage elements > > needed. > > > > procedure Allocate( > > Pool : in out Root_Storage_Pool; > > Storage_Address : out Address; > > Size_In_Storage_Elements : in Storage_Elements.Storage_Count; > > Alignment : in Storage_Elements.Storage_Count) is abstract; > > > > But after reading the following AdaCore article, my assumption is now > > called into question: > > https://blog.adacore.com/header-storage-pools > > > > In particular, the blog there advocates for separately counting for > > things like unconstrained array First/Last indices or the Prev/Next > > pointers used for Controlled objects. Normally I would have assumed > > that the Size_In_Storage_Elements parameter in Allocate would account > > for that, but the blog clearly shows that it doesn't > > > > So that seems to mean to make a storage pool, I have to make it > > compiler specific or else risk someone creating a type like an > > array and my allocation size and address values will be off. > > > > Is it intended not to be able to do portable Storage Pools or am > > I missing some Ada functionality that helps me out here. I > > scanned through the list of attributes but none seem to give > > any info about where the object's returned address is relative > > to the top of the memory actually allocated for the object. I saw > > the attribute Max_Size_In_Storage_Elements, but it doesn't seem > > to guarantee to include things like the array indices and it still > > doesn't solve the issue of knowing where the returned address > > needs to be relative to the top of allocated memory. > > > > I can easily use a generic to ensure that the types I care about > > are portably made by the pool, but I can't prevent someone from > > using my pool to create other objects that I hadn't accounted for. > > Unless there is a way to restrict a pool from allocating objects > > of other types?