Re: GCC 4.0 Ada.Containers Cursor danger.

On Sat, 9 Jul 2005 21:12:30 -0500, Randy Brukardt wrote:

> "Dmitry A. Kazakov" <mailbox@xxxxxxxxxxxxxxxxx> wrote in message
> news:1o398w3zo2zf1$.f1f7tukylueo$.dlg@xxxxxxxxxxxxx
> ...
>> I think it would be a bad design. Unordered containers should not allow
>> iteration.
>
> That's a rather silly idea.

Maybe unordered containers aren't needed at all. However as a common
[abstract] ancestor of all containers they might be useful. I think it is
logical.

> There has to be some way to find out the
> complete contents of the container, for debugging if for no other reason.
> Moreover, the implementation needs to be able to access all of the elements
> in order to stream a container, and it seems bad to have important
> capabilities that the implementation has but doesn't provide to the user.

Right, but that would be an ordered container then. Unordered = no order.

> The abstract view of iteration is that it produces *every* element of the
> container, and no others, in *some* unspecified order. That applies both the
> the passive iterator Iterate and the cursor based routines like Next.

An unspecified order is still an order. What could be said about that
unspecified order? May the order vary for a constant container? How does it
when the container gets changed? I think it is cleaner to take an ordered
copy of, or an ordered view on an unordered container and then iterate that
well-defined thing.

> Many containers have specific, stricter requirements than that. But the
> general notion does not include (nor need) a "location" or "ordering". (Here
> I disagree with Matt; his view is a bit too implementation-oriented.)
>
>> The order iteration is based on has to be documented.
>> I.e. the user should
>> know how and when the operations on the container influence that order.
>> When order is induced by some "hard" facts as below, then you can document
>> it. But I cannot see a way to document an implementation detail!
>
> It's not necessary to document the order. And there is no such requirement;
> the order is unspecified in general. Relying on the order in an iterator is
> wrong in the general case, even if there are *no* other operations.

Right, this is my concern.

> Of course, specific containers do require a specific order, and *then* you
> can rely upon it. But not in a generic algorithm.

A generic algorithm is just a class-wide procedure. The problem is the
contract of the class. If iteration is in the contract, then its behavior
must be defined. So that the correctness of the algorithm would be
independent on any possible implementation. If it is outside, then there
must be no [easy] way to use it.

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

Relevant Pages

  • Re: For vs. For Each
    ... The foreach implementation is flawed because the container is marked as ... readonly during the iteration. ... I don't see these guys on trial for that crime so i am ... > particular test data set, then you may very well create a situation where ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: For vs. For Each
    ... The foreach implementation is flawed because the container is marked as ... readonly during the iteration. ... I don't see these guys on trial for that crime so i am ... > particular test data set, then you may very well create a situation where ...
    (microsoft.public.dotnet.languages.vb)
  • Re: For vs. For Each
    ... The foreach implementation is flawed because the container is marked as ... readonly during the iteration. ... I don't see these guys on trial for that crime so i am ... > particular test data set, then you may very well create a situation where ...
    (microsoft.public.dotnet.framework)
  • Re: For vs. For Each
    ... The foreach implementation is flawed because the container is marked as ... readonly during the iteration. ... I don't see these guys on trial for that crime so i am ... > particular test data set, then you may very well create a situation where ...
    (microsoft.public.dotnet.general)
  • Re: GCC 4.0 Ada.Containers Cursor danger.
    ... complete contents of the container, for debugging if for no other reason. ... The abstract view of iteration is that it produces *every* element of the ... container, and no others, in *some* unspecified order. ... Many containers have specific, stricter requirements than that. ...
    (comp.lang.ada)