Re: asynchronous task communication

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

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