From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,81633e7277ffacee X-Google-Attributes: gid103376,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news2.google.com!newsfeed2.dallas1.level3.net!news.level3.com!newsfeed-00.mathworks.com!nntp.TheWorld.com!not-for-mail From: Robert A Duff Newsgroups: comp.lang.ada Subject: Re: Ada containers and custom allocators Date: Wed, 09 Jan 2008 16:58:22 -0500 Organization: The World Public Access UNIX, Brookline, MA Message-ID: References: <472f2c87-1238-42a5-8b94-92e9b70981da@f47g2000hsd.googlegroups.com> <1rny29vw3pipd$.oppchvpo4gnf$.dlg@40tude.net> <15hfjzq5cr38z.8ffcg9kk0ibm.dlg@40tude.net> NNTP-Posting-Host: shell01.theworld.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: pcls6.std.com 1199915902 4536 192.74.137.71 (9 Jan 2008 21:58:22 GMT) X-Complaints-To: abuse@TheWorld.com NNTP-Posting-Date: Wed, 9 Jan 2008 21:58:22 +0000 (UTC) User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.3 (irix) Cancel-Lock: sha1:/oGgxuaSzJvosi0TKS6csLsf3ak= Xref: g2news1.google.com comp.lang.ada:19301 Date: 2008-01-09T16:58:22-05:00 List-Id: "Dmitry A. Kazakov" writes: > On Wed, 09 Jan 2008 10:29:46 -0500, Robert A Duff wrote: >> Some_Ptr'Storage_Pool might be a special pool tuned for the fact that >> Size_In_Storage_Elements = 4 and Alignment = 4. Allocate could >> add 4 to a known-aligned pointer, and ignore the >> Size_In_Storage_Elements and Alignment parameters. >> >> If Boo uses this pool for something other than Integer, >> it might not work. > > Which is broken then. Because it does not fulfill the contract of > Storage_Pool'Class. What's the contract of Storage_Pool'Class? It is certainly not intended that all pools must support all sizes and alignments -- that would defeat the optimization purpose of pools. >...I guess that Allocate is allowed to raise > Storage_Error, but not to ignore parameters. Well, if it ignores the size, or raises an exception when the size is not 4, either way, it won't work when the size is not 4. But I agree that an exception is better. I'd like to suppress that check, though, if it's too slow. > If the implementation handles a family of pools one per object's size power > of two or like that, then it should return the family root rather than the > size-specific pool. What if there is no such root? How about an implementation that creates one pool for each static size that is used in the program, up to 100 bytes. Any access type whose designated type's size is nonstatic, or > 100, uses a separate pool that can handle any size, and does not call those static-size pools. Each static-size pool has the size built in to its code. Sounds like an efficient implementation. When you say "new Integer", there's no need to check the size at run time, because the compiler knows it's 4. Do you think this implementation is wrong? >...Otherwise, the following will work either: > > type Integer_Ptr is access Integer; > type Character_Ptr is access Character; > for Character_Ptr'Storage_Pool use Integer_Ptr'Storage_Pool; I don't think the RM requires the above to work properly. > I think ARM should clarify the issue of how pools could be constrained > while allowing a safe use. Perhaps. >> However, I see nothing wrong with having a predefined operation that >> returns a suitable pool. > > Yes. - Bob