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.66.86.130 with SMTP id p2mr9424200paz.22.1357876577291; Thu, 10 Jan 2013 19:56:17 -0800 (PST) MIME-Version: 1.0 Path: 6ni100196pbd.1!nntp.google.com!npeer03.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!news-in-01.newsfeed.easynews.com!easynews.com!easynews!novia!border4.nntp.dca.giganews.com!border2.nntp.dca.giganews.com!border3.nntp.dca.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!nrc-news.nrc.ca!goblin1!goblin2!goblin.stu.neva.ru!feeder.erje.net!eu.feeder.erje.net!newsfeed.straub-nv.de!nuzba.szn.dk!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: Mon, 7 Jan 2013 20:41:47 -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 1357612910 20205 69.95.181.76 (8 Jan 2013 02:41:50 GMT) X-Complaints-To: news@jacob-sparre.dk NNTP-Posting-Date: Tue, 8 Jan 2013 02:41:50 +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 X-Received-Bytes: 5556 Date: 2013-01-07T20:41:47-06:00 List-Id: "Charles Hixson" wrote in message news:E_6dnZMOnLGnJHrNnZ2dnUVZ_rednZ2d@earthlink.com... ... > 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. It definitely would be more correct, but it's unlikely to be more efficient. The issue being that the containers have to support fairly general facilities, while a custom implementation only needs to support what you actually need. Typically, it makes sense to start by using the containers, but then planning to switch to a custom structure if they are not fast enough. (It's usually very hard to tell what *really* is going to be the bottleneck until you at least have a prototype implementation to test.) But if you need access types, its pretty trivial to make a dynamic array type in Ada. Something like: type My_Vect is array (Positive range <>) of Some_Access_Type; type My_Vect_Access is access My_Vect; Then, you just allocate the size needed with new: Obj := new My_Vect (1..10); If you need to make the object bigger, just allocate a new one, copy the old one's elements into it, swap the access values, and deallocate the old one. Pretty simple. > 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. Here is where you're confused. A cursor serves the same purpose for a container that an access type serves for one of the built-in datatypes. In addition, you get some (depends on the implementation exactly how much) dangling reference detection when you use cursors. (For some implementations, it's nearly complete.) And, when you use a container to store the objects, and cursors to provide the references to them, you don't have to worry about storage management at all. The container will manage it for you. So I would probably put your objects into some container, and then use the cursors rather than access values in your Vectors. Then you can totally forget about storage management (unless and until you start running out of memory). Randy. 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. > > >