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!news4.google.com!feeder3.cambrium.nl!feed.tweaknews.nl!newsfeed.kamp.net!newsfeed.kamp.net!news.unit0.net!feeder06.uucp-net.de!news.uucp.at!news.albasani.net!nuzba.szn.dk!news.jacob-sparre.dk!pnx.dk!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Ada containers and custom allocators Date: Tue, 8 Jan 2008 17:54:44 -0600 Organization: Jacob's private Usenet server Message-ID: References: <472f2c87-1238-42a5-8b94-92e9b70981da@f47g2000hsd.googlegroups.com> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: jacob-sparre.dk 1199836497 8881 69.95.181.76 (8 Jan 2008 23:54:57 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Tue, 8 Jan 2008 23:54:57 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1914 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1914 Xref: g2news1.google.com comp.lang.ada:19283 Date: 2008-01-08T17:54:44-06:00 List-Id: "Maciej Sobczak" wrote in message news:fb7764c5-31f9-488d-a0e6-53ffd6c96182@k39g2000hsf.googlegroups.com... > On 8 Sty, 02:54, "Randy Brukardt" wrote: ... > > The standard Ada containers do not provide any mechanism to control > > how/were the container allocates memory. > > This limitation prevents programmers from doing many interesting > optimizations. Even if we put performance issues aside, I might want > to control the memory allocation for reliability. Yes, of course. It could be used for performance monitoring as well. But I wouldn't characterize it as "many" interesting optimizations, it's more like a few interesting things. But it isn't valuable enough to force every user of a container to define a storage pool (since there is no name for a standard storage pool). And we needed to keep the number of standard containers manageable. > [...] > > (or, the > > storage pool passed would have to be completely general, allowing any size > > allocation, which would eliminate the vast majority of interesting things > > that you can do with storage pools). > > There are ways to overcome this problem, at least for some container > types. Node-based containers could use fixed-size allocators, but of > course it is the container which would then instantiate the allocator > with the proper node size. It was possible in C++. Only if you put severe limits on the implementations. For one thing, you would need to know the fixed node size in the storage pool in order to take any realistic advantage of it, but you couldn't ask the container's implementation for that size since you'd have to pass the storage pool to the instance. The only practical way to do that is to *require* a particular node layout. We might as well just standardize the source code of the container body in that case. Moreover, there is no requirement in Ada that objects be laid out continuously. Janus/Ada will often make several allocator calls when allocating parts of an object, and those calls will all be different sizes. That's especially true inside of a generic body, where essentially everything that depends on a formal type is of an unknown size and thus has to be allocated separately. Even if you had the source code of the body, it probably would make different calls to Storage_Pool.Allocate on Janus/Ada and on GNAT. We'd also have to define what operations can calls the allocators. Currently, there are no such restrictions on the containers implementation. Also, of course, it would only work for a couple of the containers. All of the hashed forms also are going to allocate the hash table, so there are going to be odd-size allocations (more than just nodes). And the vectors are likely to allocate chunks of various sizes. The net effect is that this is not possible to define (or use) in any useful, portable way. (If you're willing to stick to a single vendor, then it is more possible, but that of course has nothing to do with the standard.) Combined with the inability to name the standard storage pool, there isn't much point in doing this for the primary containers. The basic idea of the containers was to define a specification, and allow implementers to innovate on the implementations. (They don't even have to be in Ada.) The extra specification required to allow passing in a storage pool would seriously reduce these possibilities. The bounded forms seem to allow even better control over dynamic allocation (by not having any in the common case, although that surely wouldn't be true for Janus/Ada), are much easier to use (don't have to write a storage pool), and would work for the high-intergrity types that cannot allow an allocator near their program. Thus, they're the first focus of work. There are a lot of other ideas, but I can't say what if anything will come of them. Randy.