Re: GCC 4.0 Ada.Containers Cursor danger.

[Georg Bauhaus <bauhaus@futureapps.de>]

Dmitry A. Kazakov wrote:

>>Unspecified order can be thought of as an advantage, too.
>>You don't have to worry about the concrete actual order generated
>>by one iteration.
> 
> 
> It must be defined. A concrete actual order, how long will it stay? Can it
> change during one iteration?

A.18 tells you what you can expect in these cases, I'd say.

If you use Ada.Containers as bricks, you may creatively expect
to be able to build walls in all sorts of ways, using skewed
stones, stones with holes, let some stones stick out, etc.
I speculate that A.18 has not been made to protect you from this
way of using the bricks; I can't find text, though, that recommends
using the low level abstractions (bricks) in ways that I would
expect to be appropriate for higher level abstractions (walls).

>>The requirements are more flexible.
> 
> 
> The most flexible requirement is an absent one...

There are quite some requirements that an implementation of
Ada.Containers must meet.


>>If you need order, why not just use a container that has a specified
>>order?
> 
> 
> Exactly. From which immediately follows that the compiler should not allow
> me to use an unordered container as if it were ordered.

"Some order" of all elements is good enough for a set that doesn't have an ordered
flavor, in the sense of Ordered_Set. Why should compilers complain, I'm content
when I can get hold of all elements in some sequence. That's because I'm using a
set, not an ordered set.

OTOH, If you write a program using a Hashed_Set, then there might be an implementation
defined order of iteration. But it is a *big* mistake IMHO to write the program
relying on a specific iteration order using a specific version of a specific
impementation of hashed sets. You can't port it. And you have missed
an opportunity to express that you want a specific order.