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: a07f3367d7,8e11100f675ea2df X-Google-Attributes: gida07f3367d7,public,usenet X-Google-NewGroupId: yes X-Google-Language: ENGLISH,ASCII-7-bit X-Received: by 10.180.79.228 with SMTP id m4mr2467674wix.7.1357876442782; Thu, 10 Jan 2013 19:54:02 -0800 (PST) Path: o9ni5955wio.1!nntp.google.com!feeder1.cambriumusenet.nl!82.197.223.103.MISMATCH!feeder3.cambriumusenet.nl!82.197.223.108.MISMATCH!feeder2.cambriumusenet.nl!feed.tweaknews.nl!85.12.40.130.MISMATCH!xlned.com!feeder1.xlned.com!border2.nntp.ams.giganews.com!border2.nntp.dca.giganews.com!border3.nntp.dca.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!nrc-news.nrc.ca!goblin3!goblin.stu.neva.ru!inn5.news.alteholz.net!easy.in-chemnitz.de!feeder.erje.net!eu.feeder.erje.net!eternal-september.org!feeder.eternal-september.org!mx04.eternal-september.org!.POSTED!not-for-mail From: Brian Drummond Newsgroups: comp.lang.ada Subject: Re: asynchronous task communication Date: Mon, 7 Jan 2013 10:49:57 +0000 (UTC) Organization: A noiseless patient Spider 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> Mime-Version: 1.0 Injection-Date: Mon, 7 Jan 2013 10:49:57 +0000 (UTC) Injection-Info: mx04.eternal-september.org; posting-host="dfff62e1e537b55df42008571c03e0fe"; logging-data="25893"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+0S6NqmiUVo0wv6A+fFc66+uhUEu7Vo68=" User-Agent: Pan/0.139 (Sexual Chocolate; GIT bf56508 git://git.gnome.org/pan2) Cancel-Lock: sha1:1RAMesdUVjXyOlwTauRjTrE28tE= Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Date: 2013-01-07T10:49:57+00:00 List-Id: On Sun, 06 Jan 2013 14:55:05 -0800, Charles Hixson wrote: > On 01/05/2013 12:48 AM, Niklas Holsti wrote: >> On 13-01-05 07:18 , Charles Hixson wrote: >>>> "Charles Hixson" wrote in message >>>> news:MY2dnX5O5NO_TXnNnZ2dnUVZ_hudnZ2d@earthlink.com... >>>> .... >>>>> And I'm sure there must be some reasonable way to deallocate a >>>>> Vector. >> If your ordinary array holds accesses to other objecs, nothing happens >> to those other objects when the array is discarded (there is no >> automatic "deep" deallocation). The same holds for Vectors: if the >> Vector holds accesses to other objecs, only the accesses are discarded >> when the Vector is discarded; nothing happens to those other accessed >> objects. >> >>> But all I really want is a variable size array. .... > It has been suggested that my intended use of Vectors is a mistake. That > it is unreasonable to store access variables into vectors. This is a > pity, as I know of no other Ada construct that would suit my needs. I think the message may have been to avoid if possible, use of access types rather than vectors! For example, Ada.Containers.Indefinite_Vectors allows variable-sized objects (not just pointers to them) to be stored in the vectors. It's probably implemented internally using access types, but that's another matter... Then how do you maintain links from one such object to others, to build a network or graph? You can access a vector element via a cursor - is it safe and reasonable to store and use cursors to maintain references to an object as the vector grows? As an alternative, wrap the access type in a controlled type, so that the controlled object can take care of deallocating the accessed resources when it is finalised - and store controlled objects in the vector. When you create such a controlled type, you can specify its Finalize operation (overriding a default) in which you can free its contents however is appropriate - decrement its reference count, Unchecked_Deallocate etc. > (I *do* need to deallocate the vectors, though. No ... when you are done with the contents, you need to *clear* the vectors. This will free their contents. If the contents are controlled types, these will be Finalized to free their own contents in turn - see above. The Barnes 2005 book mentions Clear in connection with Lists, and goes on to say that Lists and Vectors have a lot in common, so it's easy to miss that point. - Brian