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=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no 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!news3.google.com!feeder1-2.proxad.net!proxad.net!feeder2-2.proxad.net!newsfeed.arcor.de!newsspool1.arcor-online.net!news.arcor.de.POSTED!not-for-mail From: "Dmitry A. Kazakov" Subject: Re: Ada containers and custom allocators Newsgroups: comp.lang.ada User-Agent: 40tude_Dialog/2.0.15.1 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Reply-To: mailbox@dmitry-kazakov.de Organization: cbb software GmbH References: <472f2c87-1238-42a5-8b94-92e9b70981da@f47g2000hsd.googlegroups.com> <1rny29vw3pipd$.oppchvpo4gnf$.dlg@40tude.net> <15hfjzq5cr38z.8ffcg9kk0ibm.dlg@40tude.net> Date: Thu, 10 Jan 2008 11:12:56 +0100 Message-ID: <1g2a074w0yi37.2nvyj50yfwj5.dlg@40tude.net> NNTP-Posting-Date: 10 Jan 2008 11:12:59 CET NNTP-Posting-Host: 163835ed.newsspool4.arcor-online.net X-Trace: DXC=R4GIhhjo^Ah<6cDJZfMd_c4IUK\BH3YbQ]`]oVgPUXaDNcfSJ;bb[eIRnRBaCd On Wed, 09 Jan 2008 16:58:22 -0500, in comp.lang.ada you wrote: > "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. But a loose contract would make storage pools unusable. Actually it depends on the semantics of the attribute P'Storage_Pool. When the result is a constrained (optimized) pool then indeed there will be no way to fix it. >>...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. Either way is bad. Storage_Error should indicate a run-time problem, while using an inappropriate pool is just a bug, basically a type error. And it should be Constraint_Error then. >> 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? It is not wrong. Wrong is when P'Storage_Pool returns a specific pool from the family. It should return a possibly less efficient family root pool, which has to be present (when used). If an access type is created with this root pool, the implementation is free to choose a more specific pool instead. If for example the object size is known to be static. But that is an implementation detail which may not leak outside (through P'Storage_Pool, for instance). I think it should be no problem to remove the root pool altogether upon linking when it is never used, i.e. there should be no any overhead. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de