Re: GCC 4.0 Ada.Containers Cursor danger.

[Georg Bauhaus <bauhaus@futureapps.de>]

Dmitry A. Kazakov wrote:
> On Thu, 07 Jul 2005 12:38:57 +0200, Georg Bauhaus wrote:
> 
> 
>>Dmitry A. Kazakov wrote:
>>
>>>On Wed, 6 Jul 2005 18:07:38 -0500, Randy Brukardt wrote:
>>
>> 
>>
>>>>>It is not clear to me what the semantics a cursor has. Is it a location in the container?
>>
>>>>It's not a location, and it wouldn't make sense for it to be one (other than
>>>>for a Vector).
>>
>>>But it definitely refers to a location.

It designates an element.

>>> Otherwise iteration using cursor
>>>would be impossible.
>>
>>Why? A cursor designates an element. There are operations
>>on cursors, some of them let us move a cursor from one
>>element to another. Then the cursor designates another element.
> 
> 
> Rather it does some element at another location.

As long as we have no clear definition of "location",
the argument can go on. Certainly there are relative
locations if you think of a List say, this element comes
before that. There are locations implied by sorting order.
But sorting order depends on the comparison, so location
is in fact not a spatial position, but there is a position
in some sorting order. Which then isn't fixed per
element in a container. Then I might imagine an element
designated by a cursor to have a place in some imaginary
picture, hence to have a location. But I can dispense with
a location when the container's cursors actually synthesize
the elements on read, so elements don't exist at all before
--in this imaginary implementation-- my program dereferences
a cursor. The elements could be stored in some electrically
charged gel, highly dispersed. Or I could be your container
as long as my operations will give you what the operation
descriptions tell. Do I have to tell you where (and whether)
I store your information in locations?



> The element is of little
> matter here (for this concrete case, note.) Otherwise "Replace" would have
> no sense.

Sorry, I don't understand this.

> BTW the parameters of the type Cursor are routinely named
> "Position"!

Anything better?


>>I don't think there an implied requirement to think of locations.
> 
> 
> Then you have to throw out "Next", "First" etc.

I don't understand. I'm just thinking in terms of elements
and cursors that designate elements. There are subprograms
named Next, First, etc. with a description of what they do.
Where is the pressing need for a location? How do you use
"location" in your programs?

> It is the location that tells you what's next.

Next is providing me with something that designates
another element, or No_Element.
To me, that's what is next, plus what Has_Element says.
By the operations of Next, First, etc., I don't know yet what's
next. I will know what is next when I look at the element
designated by the next cursor, after Next's execution.


> As I said before, it is difficult if possible to assign any definite
> semantics to cursors, such that would be consistent across all operations
> on them.

Could you explain some inconsistencies among the Cursor
operations?