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.82.103 with SMTP id h7mr8494835pay.11.1357252079511; Thu, 03 Jan 2013 14:27:59 -0800 (PST) MIME-Version: 1.0 Path: 6ni79981pbd.1!nntp.google.com!news.glorb.com!us.feeder.erje.net!feeder.erje.net!eu.feeder.erje.net!newsfeed.x-privat.org!news.jacob-sparre.dk!munin.jacob-sparre.dk!pnx.dk!.POSTED!not-for-mail From: "Randy Brukardt" Newsgroups: comp.lang.ada Subject: Re: asynchronous task communication Date: Thu, 3 Jan 2013 16:27:49 -0600 Organization: Jacob Sparre Andersen Research & Innovation Message-ID: 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> NNTP-Posting-Host: static-69-95-181-76.mad.choiceone.net X-Trace: munin.nbi.dk 1357252077 1984 69.95.181.76 (3 Jan 2013 22:27:57 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Thu, 3 Jan 2013 22:27:57 +0000 (UTC) X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 6.00.2900.5931 X-RFC2646: Format=Flowed; Response X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.6157 Date: 2013-01-03T16:27:49-06:00 List-Id: "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). 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. 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.) 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.