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" Newsgroups: comp.lang.ada Subject: Re: Custom Storage Pool questions Date: Mon, 13 Sep 2021 00:29:35 -0500 Organization: JSA Research & Innovation Message-ID: References: Injection-Date: Mon, 13 Sep 2021 05:29:37 -0000 (UTC) Injection-Info: franka.jacob-sparre.dk; posting-host="rrsoftware.com:24.196.82.226"; logging-data="22031"; 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:62718 List-Id: 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). 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. 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). More likely, you'll build a pool for a particular implementation. Pools are very low level by their nature, and useful ones are even more so (because they are using target facilities to allocate memory, or need to assume something about the allocations, or because they are doing icky things like address math, or ...). Randy. Randy. "Jere" wrote in message news:e3c5c553-4a7f-408a-aaa7-60ec0b70202dn@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?