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,427e29f23a651ddb X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news1.google.com!news2.google.com!news.glorb.com!news-out1.kabelfoon.nl!newsfeed.kabelfoon.nl!bandi.nntp.kabelfoon.nl!213.132.189.2.MISMATCH!multikabel.net!feed20.multikabel.net!amsnews11.chello.com!nuzba.szn.dk!news.jacob-sparre.dk!pnx.dk!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: Finding out minimal allocation unit Date: Thu, 5 Apr 2007 20:31:42 -0500 Organization: Jacob's private Usenet server Message-ID: References: <20070403144350.6c95e085@cube.tz.axivion.com> <1175606570.4684.11.camel@localhost> <461257ea$1@news.post.ch> <4ecea2f308sbellon@sbellon.de> <4ecee3fe5esbellon@sbellon.de> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: jacob-sparre.dk 1175823010 25023 69.95.181.76 (6 Apr 2007 01:30:10 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Fri, 6 Apr 2007 01:30:10 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2800.1807 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1807 Xref: g2news1.google.com comp.lang.ada:14801 Date: 2007-04-05T20:31:42-05:00 List-Id: "Stefan Bellon" wrote in message news:4ecee3fe5esbellon@sbellon.de... > Robert A Duff wrote: > > > There are many ways to do it. In your case, you have a large number > > of small objects. In that case, it would make sense to allocate > > large chunks of memory (possibly using "new"), and then have Allocate > > chop them up into small pieces on request. > > This sounds good, provided that > > a) we can resize an already existing storage pool to increase the > memory inside it, and It's whatever you want it to be! A storage pool is just a container that is automatically called when you allocate or deallocate memory. There of course are the predefined ones, but you can provide your own about which you define *all* of the details. In your case, I'd probably implement the pool as a linked list of arrays that hold enough elements for some large size (at least 4K for Windows, can't say for Linux). And then I'd manage them with a free chain and a pass through for unusual sizes (see below). You could even set the item size as a discriminant of the pool type, possibly using the attribute designed for this purpose ('Max_Size_in_Storage_Elements). > b) we can really get at the size GNAT uses for each of the items (see > my other posting with the unbounded string example). I don't know about that for certain (I don't use GNAT that much), but I'd be fairly surprised if it wasn't. To some extent it is irrelevant, since the size to allocate is passed into Allocate, and it is easy enough to have unanticipated sizes just allocate from the regular pool (i.e. use New). Indeed, I have a pool whose job was to find the source of dangling pointers, and all it did was save the pointers and clobber memory on deallocation; the actual allocation was a pure pass-through to the standard pool (using New and Unchecked_Deallocation). I suggest reading up on storage pools in whatever you can find. As Bob said, this is low-level programming; Ada won't be much help if you screw up -- if you give non-existent memory to Ada, she will screw up just like those other language some of us love to hate. It's likely that most of the pools that have been written are specific to some OS or compiler, which may explain why there aren't many out there. (Mine are all specific to Janus/Ada; not much use to you.) But they can be fairly generic (allocating large chunks from the regular heap), and reasonably well-checked: you don't have to write them solely with pointer arithmetic. Randy.