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!news.germany.com!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: Thu, 10 Jan 2008 23:00:01 -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 1200077995 26660 69.95.181.76 (11 Jan 2008 18:59:55 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Fri, 11 Jan 2008 18:59:55 +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:19323 Date: 2008-01-10T23:00:01-06:00 List-Id: "Robert A Duff" wrote in message news:wcclk6zc91o.fsf@shell01.TheWorld.com... > "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. Maybe, but that could be a substantially worse pool on some implementations than used for normal access types. So I'm unsure if that is a good idea. > >... 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. OK, but only if you are willing to leave absolutely everything about how the pool is used implementation-defined. At which point, I have to wonder what the point is: you couldn't do anything at all portably. Otherwise, you're going to have to have wording about where user-defined pool operations can be called, what happens to the exceptions that they propagate, and possibly other issues that I haven't thought about yet. This isn't going to be a single sentence change -- maybe more like the magnitude of "Wide String Handling" (A.4.7). ... > > Moreover, there is no requirement in Ada that objects be laid out > > continuously. > > Perhaps there should be! Over my dead body. A serious attempt to propose that would get very, very nasty. > 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. Correct. But it means that little useful can be done with custom pools on the predefined containers libraries. The needed generality prevents using any optimizations in the pool, so it pretty much limits you to tracking the allocations and deallocations. ... > > We'd also have to define what operations can calls the allocators. > > I don't see why. The current containers library spends quite a bit of effort defining the places where objects can be destroyed (that is, where Finalize can be called). Admittedly, a lot of that effort is to say that it isn't defined closely. But one thing we don't do is allow random calls to reading operations to call Finalize. Similarly, we always have wording to define what and where exceptions are propagated. If we allow user storage pools, we'd need the definitions of where those operations can be called (hopefully not in operations that merely read and return something!) and wording to say that the exceptions are propagated. And probably other things as well. > > 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 OP claimed that fixed-size allocators could be used, and my lengthy reply was intended to rebut that. Surely, they can't be used portably or generally. It is true that you probably could do it on a specific implementation for a specific element type (it would even work on Janus/Ada that way). But as soon as you move to a different compiler (or even potentially an update for the same compiler with an "improved" containers library), it will no longer work. That might make sense to do for debugging, but it can't be used for anything long term. All of which begs the question of whether it is worth the work to accomplish. Randy. Of