From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.4
X-Google-Thread: 103376,f2690a5e963b61b6
X-Google-Attributes: gid103376,public
X-Google-Language: ENGLISH,ASCII-7-bit
Path: 
 g2news1.google.com!news3.google.com!news.glorb.com!atl-c03.usenetserver.com!news.usenetserver.com!atl-c08.usenetserver.com!news.usenetserver.com!pc03.usenetserver.com!ALLTEL.NET-a2kHrUvQQWlmc!not-for-mail
Date: Tue, 12 Jul 2005 12:44:08 -0500
From: "Marc A. Criley" <mcNOSPAM@mckae.com>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
Newsgroups: comp.lang.ada
Subject: Re: GCC 4.0 Ada.Containers Cursor danger.
References: <1120474891.635131.216700@g44g2000cwa.googlegroups.com>
   <1120575076.876798.108220@g44g2000cwa.googlegroups.com>
   <1120583470.429264.325450@g43g2000cwa.googlegroups.com>
   <osoo6gccqpnm.2o5eehhafwb1.dlg@40tude.net>
   <42cb8d21$0$22761$9b4e6d93@newsread2.arcor-online.net>
   <ldco4pwrxop4$.1py0a7isiagea.dlg@40tude.net>
   <z--dnRI60_7j_lHfRVn-qw@megapath.net>
   <tyi72ga8ch55$.3tea03tbwrtx.dlg@40tude.net>
   <42cd064c$0$10817$9b4e6d93@newsread4.arcor-online.net>
   <k62rlp2n1ls3.1cnwufmnuit7v.dlg@40tude.net>
   <42cda8c4$0$22780$9b4e6d93@newsread2.arcor-online.net>
   <1u3hh2597i4ne$.1ryetugksbmus.dlg@40tude.net>
   <uslyp8mmb.fsf@earthlink.net>
   <1121093807.949660.274060@g44g2000cwa.googlegroups.com>
   <1121124248.600055.292320@f14g2000cwb.googlegroups.com>
   <1121137531.752285.44280@g44g2000cwa.googlegroups.com>
   <946e7$42d3c64d$4995421$28449@ALLTEL.NET>
 <1121179909.262566.192270@o13g2000cwo.googlegroups.com>
In-Reply-To: <1121179909.262566.192270@o13g2000cwo.googlegroups.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Message-ID: <5a73f$42d40166$4995149$5993@ALLTEL.NET>
X-Complaints-To: abuse@usenetserver.com
Organization: UseNetServer.com
X-Trace: 5a73f42d40166a13cf4ec05993
Xref: g2news1.google.com comp.lang.ada:12016
Date: 2005-07-12T12:44:08-05:00
List-Id: <comp.lang.ada>

MMM wrote:

<forContext>
I wrote:
 >> If the container is identified as being "unordered", e.g. set or map,
 >> then it is a programming error to rely on elements being produced,
 >> via iterator or cursor, in any particular/repeatable order.
 >>
 >> If I needed to rely on the ordering--in the same or across
 >> implementations--I would utilize an "ordered" container.

</forContext>

> Exactly. But the original claim was that "unordered" containers do not
> exist.

Unordered vs ordered vs sorted is part of the abstraction.  A plain 
vanilla "set" is unordered, even though any implementor knows there's 
going to be an internal ordering that is used for iterating and such.

 From the point of view of my application utilizing an unordered set 
container, there can be no expected ordering of the elements, and 
relying upon (or even expecting) one when sequentially processing the 
container's contents would be a programming error.

-- Marc A. Criley
-- www.mckae.com
-- DTraq - XPath In Ada - XML EZ Out --