Re: asynchronous task communication

[Charles Hixson <charleshixsn@earthlink.net>]

On 01/03/2013 02:27 PM, Randy Brukardt wrote:
> "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).
Well, I've now been through the relevant section of the AARM, and 
there's nothing about deallocating Vectors.  The contents of the vector, 
yes, but not the vector itself.  Perhaps this means it's safe to use 
Unchecked_Deallocation on the vector, as long as *I* don't have any 
dangling pointers.
>
> 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.
It would be possible to put the objects directly into the containers, I 
think.  But they will be changing a lot, and copying them in and out 
would be undesirable.  But my main reason for using the container is to 
get a variable size array.  (Second thoughts:  No, it wouldn't be 
possible to put the items into a container, if I substitute item for 
access variables, because there is a mutual reference and forward 
reference, and everything would end up as one big lump.)
>
> 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.)
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.
>
> 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.
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.  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.