Re: asynchronous task communication

["Randy Brukardt" <randy@rrsoftware.com>]

"Charles Hixson" <charleshixsn@earthlink.net> 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.
>
>
>