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!border1.nntp.dca.giganews.com!nntp.giganews.com!local01.nntp.dca.giganews.com!nntp.megapath.net!news.megapath.net.POSTED!not-for-mail
NNTP-Posting-Date: Tue, 19 Jul 2005 19:07:48 -0500
From: "Randy Brukardt" <randy@rrsoftware.com>
Newsgroups: comp.lang.ada
References: <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>
   <5a73f$42d40166$4995149$5993@ALLTEL.NET>
 <1121194262.036046.38230@g49g2000cwa.googlegroups.com>
 <Z4udnUiH7NtDsEnfRVn-3w@megapath.net> <CkmBe.7957$rX7.329@fe06.lga>
Subject: Re: GCC 4.0 Ada.Containers Cursor danger.
Date: Tue, 19 Jul 2005 19:10:55 -0500
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Outlook Express 5.50.4952.2800
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4952.2800
Message-ID: <DNydnbVWEb9JCEDfRVn-vA@megapath.net>
NNTP-Posting-Host: 64.32.209.38
X-Trace: 
 sv3-1vdsLXlObsY+RbGyuIYiDLNWR+8swbdNFyGIc4Ud3cu9kACPRnzixl9lduzqAeBQYc8GepXj9qqyPkh!fqDrhS7cXESlnDWbP5NEMYwyTdT9Xae06TPOf/CPq5VyNljJ0IxmUiVjO7wYq9v+Y8XoElp2NMs1
X-Complaints-To: abuse@megapath.net
X-DMCA-Complaints-To: abuse@megapath.net
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint
 properly
X-Postfilter: 1.3.31
Xref: g2news1.google.com comp.lang.ada:3684
Date: 2005-07-19T19:10:55-05:00
List-Id: <comp.lang.ada>

"Mikhail Terekhov" <terekhov@emc.com> wrote in message
news:CkmBe.7957$rX7.329@fe06.lga...
...
> > Ada.Containers just provides a foundation and vision for future work.
And I
>
> That is exactly why it concerns me! Foundation and vision based on some
> biased concepts is not the best one. Ada was created to replace hundreds
> of home grown special case languages with one unified, scientifically
> well-founded language. Current Ada.Containers library overemphasize
> significance of order and efficiency over clarity.

Fair enough, but you're very much in the minority. Specifying the efficiency
was considered very important by most of the people involved with the
design. So your "unordered sets" would have to have an efficiency
requirement attached.

Now, there seem to be two practical implementations for an unordered set, as
a list or as a tree (like an ordered set). The list implementation has much
worse efficiency requirements than the ordered set for all of the complex
operations. So why would anyone use such a container? The only possible
reason is that they don't need the complex operations - in which case using
a list directly works just as well. And if we specify a tree implementation,
the unordered set is identical to the ordered set. So it's just duplication,
making it harder for users to choose the appropriate container.

You may not care about these issues, but we had to. And that is why we
choose the set of containers that we did.

                              Randy.