Re: GCC 4.0 Ada.Containers Cursor danger.

["MMM" <terekhov@emc.com>]

"Matthew Heaney" <mheaney@on2.com> wrote in message
news:1121124248.600055.292320@f14g2000cwb.googlegroups.com...
>
> Unordered containers do not exists.  The problem is nomenclature.
> "Hashed" containers are of course ordered, but the order isn't
> specified.
>

You are mixing abstraction and implementation here. Of course during
a program run when container has been created and populated, there is
*some* order of elements. But there is no guarantee that the same order
will be provided in some other implementation. Other implementation
can use compleetely different hashing algorithm or just some different
load factor. Even in the same implementation the order could be
different (imagine an implementation where bucket is choosen using
random number). Bottom line: if an order of elements in a collection
for
the same application depends on the library implementation, or is
random, then from the API point of view - there is no order. If you
still
want to provide an order to hash implementation then API should
explicitly say what kind of order and should guarantee it across
implementations. My point is that while probably useful, this ordered
abstraction is a specialisation or extension to the basic
functionality.
See for example Java version of SortedSet.

>
>> > The "position" of an element always relative to other elements in the
>>
>> That depends on the semantic. For example the Hashed_Sets in your
>> terminology requires no "relative position" semantic.
>
> Not quite.  For hashed containers there is indeed a relative position,
> but it's not specified.  (There must be *some* order, to deliver
> elements via the iterators.)

Again, if you can't guarantee the order or do not require some order,
then
from the API point of view - there is *no* order. Of course there is
*some*
order, but this order will vary depending on the implementation or "the

phase of the moon" which can't be the base for the standard.

>
>
>> The fact that an
>> implementation will use some "relative position" semantic internaly is
>> an implementation detail. This internal relative position can be
>> different for the same set in different hash implementations.
>
> Yes.  The standard doesn't specify the order in which elements (of a
> hashed container) are delivered via iterators, so different
> implementations can vary.  (Among other things, implementations can
> vary because the standard doesn't specify the hash table load factor.)
>
>
>> > container.  For an "ordered" container (Ordered_Sets, Ordered_Maps), the
>> > position is determined by the "<" operator for elements.  For a "hashed"
>>
>> This is a confusion. The "<" operator defines relative order, not
>> position.
>
> You say to-MAY-to, I say to-MAH-to.  It's the same.
>

Yes, it is the same, while we are talking in a bar, siping beer and
bashing MS.
When we are talking about standards - there is a difference.

>
>> > An iterator (either passive or active) simply enumerates elements in
>> > their order as specified by the type of container they're in (either
>>
>> Exactly! Note also that the natural name for this is "iterator" not
>> "cursor".
>
> You say "chien", I say "dog".  It's the same.
>
Sure it is the same. So why to change? Just to be different?