Re: GCC 4.0 Ada.Containers Cursor danger.

On Wed, 6 Jul 2005 18:07:38 -0500, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@xxxxxxxxxxxxxxxxx> wrote in message
> news:ldco4pwrxop4$.1py0a7isiagea.dlg@xxxxxxxxxxxxx
> ...
>> "All of the containers specify positions using a cursor,
>> which is similar to an access type in that it designates an element."
>>
>> So? Is it position or access?
>
> We don't say, on purpose. Its is not either, it has elements of both. It
> doesn't matter anyway.

That's the point. In my view a decision about which checks are appropriate
must follow from the semantics of the thing. Especially the case of mutable
containers shows the problem. Depending on whether cursors are bound to a
container's location, an element at some specific location, the element at
a location, one or another implementation requirement should follow.

>>It is not clear to me what the semantics a cursor has. Is it a location in the container?
>>Then that should be an index or position.
>
> It's not a location, and it wouldn't make sense for it to be one (other than
> for a Vector). A linked list position, for instance, would require a O(N)
> walk through the list. Yuck.

But it definitely refers to a location. Otherwise iteration using cursor
would be impossible. So it is to define what precisely happens when the
location it refers disappear. Or when the element it refers goes to another
location etc. So far it seems that the *implied* semantics is sort of "the
element at the location". Which is obviously incompatible with many
operations on mutable containers.

>> Is it a pointer to an individual element? Then that should be an access type object.
>
> No. A raw access type could never be checked, while a Cursor can (and IMHO,
> should) be checked for problems.

Ditto

>> Cursor looks like an amorphous mixture inheriting disadvantages of both.
>
> We don't say exactly what it is in part because it is different for the
> different containers. But you still can use the same abstraction on any
> container.

The problem with cursors is that they are quite difficult to get right for
mutable containers. I tend to believe that cursor is a wrong abstraction
there.

--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
.

Relevant Pages

  • Re: GCC 4.0 Ada.Containers Cursor danger.
    ... > "All of the containers specify positions using a cursor, ... >It is not clear to me what the semantics a cursor has. ... A linked list position, for instance, would require a O ... A raw access type could never be checked, while a Cursor can (and IMHO, ...
    (comp.lang.ada)
  • Re: OO Style with Ada Containers
    ... Ada.Containers can be compared to Java containers on the basis that ... cursor/iterator and this is different from both STL and Java (STL ... procedure Generic_Algorithm (C: Cursor); ...
    (comp.lang.ada)
  • Re: Rational for not making cursor tagged in Containers
    ... However, when it comes to Containers, I can not use this notation ... on cursor because it is not tagged. ... And yet, overhead was already paid. ...
    (comp.lang.ada)
  • Re: Rational for not making cursor tagged in Containers
    ... However, when it comes to Containers, I can not use this notation ... on cursor because it is not tagged. ... Why is the prefix notation not allowed ... I'm not a big fan of prefix notation, ...
    (comp.lang.ada)