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!news.glorb.com!newscon02.news.prodigy.net!prodigy.net!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 10:28:51 -0500 Organization: The World Public Access UNIX, Brookline, MA Message-ID: References: <472f2c87-1238-42a5-8b94-92e9b70981da@f47g2000hsd.googlegroups.com> NNTP-Posting-Host: shell01.theworld.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: pcls6.std.com 1199892532 12153 192.74.137.71 (9 Jan 2008 15:28:52 GMT) X-Complaints-To: abuse@TheWorld.com NNTP-Posting-Date: Wed, 9 Jan 2008 15:28:52 +0000 (UTC) User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.3 (irix) Cancel-Lock: sha1:a9b3btAzGGF3OE2GyRO7fJK+8vY= Xref: g2news1.google.com comp.lang.ada:19291 Date: 2008-01-09T10:28:51-05:00 List-Id: "Randy Brukardt" writes: > 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). That seems easy enough to fix. Simply have a predefined function: type Storage_Pool_Pointer is access all Root_Storage_Pool'Class; function Default_Storage_Pool return Storage_Pool_Pointer; and use that for the default in the generic. Default_Storage_Pool must be general enough to support any size. There's no requirement that this be the same pool used by default for misc access types. >... And we needed to keep the number of standard > containers manageable. I suppose, but we weren't shy about writing macros in English -- see for example package Float_Text_IO. It would take one paragraph in the RM to double the number of container packages by having versions with a Pool parameter. Pretty ugly, but there's precedent. >> [...] >> > (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. Perhaps there should be! But anyway, given this fact, user-defined storage pools need to be fully general (accept any size), or else depend on details of the Ada implementation. This is not specific to containers. >...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. I don't see why. > 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. It can work -- you just can't take advantage of (say) fixed sized chunks. I guess what you're saying is that that defeats the main purpose! > 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. - Bob