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!news.germany.com!newsfeed.arcor.de!news.arcor.de!not-for-mail Date: Mon, 11 Jul 2005 15:50:46 +0200 From: Georg Bauhaus Organization: future apps GmbH User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050513 Debian/1.7.8-1 X-Accept-Language: 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> <42cb8d21$0$22761$9b4e6d93@newsread2.arcor-online.net> <42cd064c$0$10817$9b4e6d93@newsread4.arcor-online.net> <42cda8c4$0$22780$9b4e6d93@newsread2.arcor-online.net> <1u3hh2597i4ne$.1ryetugksbmus.dlg@40tude.net> <42ce5856$0$22762$9b4e6d93@newsread2.arcor-online.net> <1o398w3zo2zf1$.f1f7tukylueo$.dlg@40tude.net> <42d250da$0$18021$9b4e6d93@newsread4.arcor-online.net> <1vw0rnx2kbjd1.1s1tkdmfj0bos$.dlg@40tude.net> In-Reply-To: <1vw0rnx2kbjd1.1s1tkdmfj0bos$.dlg@40tude.net> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <42d27935$0$18023$9b4e6d93@newsread4.arcor-online.net> NNTP-Posting-Date: 11 Jul 2005 15:50:45 MEST NNTP-Posting-Host: 2bf6cb8f.newsread4.arcor-online.net X-Trace: DXC=@H9:=P9Ihe`BH@Z?dZ]MOidE X-Complaints-To: abuse@arcor.de Xref: g2news1.google.com comp.lang.ada:11995 Date: 2005-07-11T15:50:45+02:00 List-Id: 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.