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.0 required=3.0 tests=BAYES_40,FREEMAIL_FROM autolearn=ham autolearn_force=no version=3.4.6 X-Received: by 2002:a37:aa97:: with SMTP id t145mr7686374qke.145.1631494427590; Sun, 12 Sep 2021 17:53:47 -0700 (PDT) X-Received: by 2002:a5b:142:: with SMTP id c2mr12074937ybp.425.1631494427362; Sun, 12 Sep 2021 17:53: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: Sun, 12 Sep 2021 17:53:47 -0700 (PDT) Injection-Info: google-groups.googlegroups.com; posting-host=98.118.241.166; posting-account=QF6XPQoAAABce2NyPxxDAaKdAkN6RgAf NNTP-Posting-Host: 98.118.241.166 User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Custom Storage Pool questions From: Jere Injection-Date: Mon, 13 Sep 2021 00:53:47 +0000 Content-Type: text/plain; charset="UTF-8" Xref: reader02.eternal-september.org comp.lang.ada:62717 List-Id: 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?