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:ac8:187:: with SMTP id x7mr5826640qtf.66.1633216794005;
        Sat, 02 Oct 2021 16:19:54 -0700 (PDT)
X-Received: by 2002:a25:8b87:: with SMTP id j7mr5563970ybl.452.1633216793856;
 Sat, 02 Oct 2021 16:19:53 -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: Sat, 2 Oct 2021 16:19:53 -0700 (PDT)
In-Reply-To: <siu6f6$t4e$1@franka.jacob-sparre.dk>
Injection-Info: google-groups.googlegroups.com; posting-host=98.118.241.166; posting-account=QF6XPQoAAABce2NyPxxDAaKdAkN6RgAf
NNTP-Posting-Host: 98.118.241.166
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>
 <siba8v$nvh$1@franka.jacob-sparre.dk> <6a073ced-4c3b-4e87-8063-555a93a5c3f6n@googlegroups.com>
 <siu6f6$t4e$1@franka.jacob-sparre.dk>
User-Agent: G2/1.0
MIME-Version: 1.0
Message-ID: <3ab4890a-7787-480b-b44b-5189309c8693n@googlegroups.com>
Subject: Re: Custom Storage Pool questions
From: Jere <jhb.chat@gmail.com>
Injection-Date: Sat, 02 Oct 2021 23:19:54 +0000
Content-Type: text/plain; charset="UTF-8"
Xref: reader02.eternal-september.org comp.lang.ada:62926
List-Id: <comp.lang.ada>

I was thinking more along the lines of adding a classwide operation on the 
root storage pool type.  That shouldn't change anyone's implementation
ideally.  Something like:

    -- Parameter is mode "in out" to allow for it to clear itself if the implementation
    -- so desires
    function Is_First_Allocation(Self : in out Root_Storage_Pool'Class) return Boolean;

Added to System.Storage_Pools.  Allow the implementation to implement it
however they like under the hood.  They could, for example, add a boolean
to the private part of the root storage pool and add a child function/package that 
sets it when the compiler implementation calls for the first allocation.  It can be 
implemented with a count.  I'm sure there are a plethora of ways.

Since the operation is classwide and it is optional, it wouldn't affect anyone's
existing storage pools.  it would basically just be there to give custom
storage pool designers a hook to know when it is portably safe to add
a custom header, regardless of the number of allocations an implementation
chooses to do.

It does place the burden on the compiler implementors to call it for the first
allocation, but I can't imagine that is a huge burden with today's IDE tools?

On Tuesday, September 28, 2021 at 12:42:16 AM UTC-4, Randy Brukardt wrote:
> "Jere" <> wrote in message
> news:6a073ced-4c3b-4e87...@googlegroups.com... 
> ...
> > 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,
> We tried that as a solution for the user-defined dereference problem, and it 
> ended up going nowhere. Your problem is different but the issues of changing 
> the Storage_Pool spec remain. Not sure it could be made to work (one does 
> not want to force everyone to change their existing storage pools). 
> 
> Randy.