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: Sat, 09 Jul 2005 21:09:23 -0500 From: "Randy Brukardt" Newsgroups: comp.lang.ada 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> Subject: Re: GCC 4.0 Ada.Containers Cursor danger. Date: Sat, 9 Jul 2005 21:12:30 -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: NNTP-Posting-Host: 64.32.209.38 X-Trace: sv3-ToYNE7v4QfYP91IVrw+j/RSwgrYncs3qyr1dqs2kSWjDMPYseZ5ogpQUFe8dFHALxKVI/ol8eoOTiXe!jk1RP7GW/5folZZDSfjUdXcOpE6FvBHPM5Vu508X+Mn94+zrvpQh1yb+8SbysxAsi8jrCSudpFjD 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:11980 Date: 2005-07-09T21:12:30-05:00 List-Id: "Dmitry A. Kazakov" wrote in message news:1o398w3zo2zf1$.f1f7tukylueo$.dlg@40tude.net... ... > I think it would be a bad design. Unordered containers should not allow > iteration. That's a rather silly idea. There has to be some way to find out the complete contents of the container, for debugging if for no other reason. Moreover, the implementation needs to be able to access all of the elements in order to stream a container, and it seems bad to have important capabilities that the implementation has but doesn't provide to the user. The abstract view of iteration is that it produces *every* element of the container, and no others, in *some* unspecified order. That applies both the the passive iterator Iterate and the cursor based routines like Next. Many containers have specific, stricter requirements than that. But the general notion does not include (nor need) a "location" or "ordering". (Here I disagree with Matt; his view is a bit too implementation-oriented.) > The order iteration is based on has to be documented. > I.e. the user should > know how and when the operations on the container influence that order. > When order is induced by some "hard" facts as below, then you can document > it. But I cannot see a way to document an implementation detail! It's not necessary to document the order. And there is no such requirement; the order is unspecified in general. Relying on the order in an iterator is wrong in the general case, even if there are *no* other operations. Of course, specific containers do require a specific order, and *then* you can rely upon it. But not in a generic algorithm. Randy.