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,8e11100f675ea2df X-Google-NewGroupId: yes X-Google-Attributes: gida07f3367d7,domainid0,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit X-Received: by 10.66.72.134 with SMTP id d6mr7989731pav.20.1357363515152; Fri, 04 Jan 2013 21:25:15 -0800 (PST) Path: 6ni82910pbd.1!nntp.google.com!news.glorb.com!border3.nntp.dca.giganews.com!Xl.tags.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local2.nntp.dca.giganews.com!nntp.earthlink.com!news.earthlink.com.POSTED!not-for-mail NNTP-Posting-Date: Fri, 04 Jan 2013 23:25:14 -0600 Date: Fri, 04 Jan 2013 21:18:56 -0800 From: Charles Hixson User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.11) Gecko/20121122 Icedove/10.0.11 MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: asynchronous task communication References: <1c2dnd5E6PMDR33NnZ2dnUVZ_sednZ2d@earthlink.com> <50e18094$0$6583$9b4e6d93@newsspool3.arcor-online.net> <7NednS4s2oukfXzNnZ2dnUVZ_oadnZ2d@earthlink.com> <7cudnYloBfQDw3_NnZ2dnUVZ_rKdnZ2d@earthlink.com> <6bqdndEYjoxeGHnNnZ2dnUVZ_sadnZ2d@earthlink.com> In-Reply-To: Message-ID: X-Usenet-Provider: http://www.giganews.com NNTP-Posting-Host: 216.244.16.210 X-Trace: sv3-IB2YUu4zglnYOs4p7HhEYhFUHofSCVmpb89Wa5G1Al+T1Y5fhrRFsLNCPkcZ9/sl2ky6mbLeQv15efk!3bu/Esf44NnMi6UomrZOovYuCIaCGNuJEx6GCfbtZy1BHuE/f3aYwGTh13NBvIJcv/jYrBkZjX2K!huKgdpIO3Uh7zIWyLBAG/g== X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly X-Postfilter: 1.3.40 X-Original-Bytes: 7070 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Date: 2013-01-04T21:18:56-08:00 List-Id: On 01/03/2013 02:27 PM, Randy Brukardt wrote: > "Charles Hixson" wrote in message > news:MY2dnX5O5NO_TXnNnZ2dnUVZ_hudnZ2d@earthlink.com... > .... >> Yes, it's doable, but I'd *really* rather avoid that. And I'm sure there >> must be some reasonable way to deallocate a Vector. That I don't know >> what it is doesn't convince me that it doesn't exist. Perhaps Clear or >> Delete would do it, but I haven't found this documented. I'm guessing >> that if I store access variables in a Vector, and then deallocate the item >> the access variable holds (updating the access variable to null), that >> will free most of the space, but deallocating the Vector itself is not so >> clear. I can't tell whether there are any handles to it that I don't know >> about. Perhaps it's somewhere in the AARM. > > I don't understand this comment (and probably no one else has, either, as no > one has commented on it). Well, I've now been through the relevant section of the AARM, and there's nothing about deallocating Vectors. The contents of the vector, yes, but not the vector itself. Perhaps this means it's safe to use Unchecked_Deallocation on the vector, as long as *I* don't have any dangling pointers. > > The entire reason the Ada.Containers library of packages (including Vectors) > exists is to eliminate the need to manage storage. (If you don't mind > managing the storage, the operations are trivial to write yourself, and > probably more efficient as well.) As such, there is quite purposely no > visibility into the storage management of any of the Ada.Containers. All > that's required is that the memory is freed when the object is destroyed or > overwritten (see A.18.2(253)). > > Of course, if you're putting an access to some object into a container, you > still have to manage the storage for the object. It's better (but not always > possible) to put the objects themselves directly into the containers. When > that's not possible, sometimes its possible to put cursors (for another > container) into a container. In both cases, the containers will manage the > storage so you don't have to. It would be possible to put the objects directly into the containers, I think. But they will be changing a lot, and copying them in and out would be undesirable. But my main reason for using the container is to get a variable size array. (Second thoughts: No, it wouldn't be possible to put the items into a container, if I substitute item for access variables, because there is a mutual reference and forward reference, and everything would end up as one big lump.) > > Personally, I wouldn't bother with using a Vector container for access > values. You're still going to have to do most of the storage management > yourself; you might as well do all of it yourself. An access to > unconstrained array of access values is easy to manage and you won't have > any questions about when memory is freed. The most painful case happens when > you need to grow the structure, but just copying it into a larger value is > not likely to be very expensive because of the small size of the > elements.(After all, this is pretty much what is happening inside of an > instance of Vectors.) You are probably right that a good custom implementation would be more efficient, but (as is probably obvious) I'm not very familiar with Ada. So my presumption has been that the library implementation would not only be much more likely to be correct than something that I wrote, but that it would also be more efficient. > > The big value of the containers is when managing large elements directly, > especially indefinite elements like class-wide objects (something Ada > doesn't allow you to do directly). Just because you *can* store access > values into a container doesn't mean you should. But of course YMMV. > > Randy. Well, the things that I'm planning on managing are themselves indefinite in size, in that they contain variable length arrays, So an access type seems the right handle. Besides, that allows me to call routines that modify them without copying the whole thing. But all I really want is a variable size array. The fancy stuff, like cursors, etc., don't seem to have any application to my purpose. I want an array, because I want to be able to directly address individual items. OTOH, I don't even see that I need to use tagged types, much less class wide variables. So maybe containers is the wrong thing to look at. But it was the only variable size array library that I found. Please note that when I say variable size, I'm not talking about indefinite. At each instant the array is definite in size...but the size isn't a constant. This kind of thing is normally implemented by an thing that starts at some base size, and whenever it runs out of space it allocates a new copy on the heap that will hold perhaps twice as many items, and references to this new item replace the old item. Which is the kind of thing I thought Ada.Containers.Vectors was. But details of the implementation are important if you want this to be efficient, so I thought I'd use the Ada.Containers library version. It sounds like this was a mistake.