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!postnews.google.com!g44g2000cwa.googlegroups.com!not-for-mail From: "MMM" Newsgroups: comp.lang.ada Subject: Re: GCC 4.0 Ada.Containers Cursor danger. Date: 11 Jul 2005 20:05:31 -0700 Organization: http://groups.google.com Message-ID: <1121137531.752285.44280@g44g2000cwa.googlegroups.com> 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> <1121093807.949660.274060@g44g2000cwa.googlegroups.com> <1121124248.600055.292320@f14g2000cwb.googlegroups.com> NNTP-Posting-Host: 24.107.234.224 Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Trace: posting.google.com 1121137538 30537 127.0.0.1 (12 Jul 2005 03:05:38 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Tue, 12 Jul 2005 03:05:38 +0000 (UTC) In-Reply-To: <1121124248.600055.292320@f14g2000cwb.googlegroups.com> User-Agent: G2/0.2 Complaints-To: groups-abuse@google.com Injection-Info: g44g2000cwa.googlegroups.com; posting-host=24.107.234.224; posting-account=0PrGnQwAAAAhG4fw_pPdaColajHpyOJW Xref: g2news1.google.com comp.lang.ada:12006 Date: 2005-07-11T20:05:31-07:00 List-Id: "Matthew Heaney" wrote in message news:1121124248.600055.292320@f14g2000cwb.googlegroups.com... > > Unordered containers do not exists. The problem is nomenclature. > "Hashed" containers are of course ordered, but the order isn't > specified. > You are mixing abstraction and implementation here. Of course during a program run when container has been created and populated, there is *some* order of elements. But there is no guarantee that the same order will be provided in some other implementation. Other implementation can use compleetely different hashing algorithm or just some different load factor. Even in the same implementation the order could be different (imagine an implementation where bucket is choosen using random number). Bottom line: if an order of elements in a collection for the same application depends on the library implementation, or is random, then from the API point of view - there is no order. If you still want to provide an order to hash implementation then API should explicitly say what kind of order and should guarantee it across implementations. My point is that while probably useful, this ordered abstraction is a specialisation or extension to the basic functionality. See for example Java version of SortedSet. > >> > The "position" of an element always relative to other elements in the >> >> That depends on the semantic. For example the Hashed_Sets in your >> terminology requires no "relative position" semantic. > > Not quite. For hashed containers there is indeed a relative position, > but it's not specified. (There must be *some* order, to deliver > elements via the iterators.) Again, if you can't guarantee the order or do not require some order, then from the API point of view - there is *no* order. Of course there is *some* order, but this order will vary depending on the implementation or "the phase of the moon" which can't be the base for the standard. > > >> The fact that an >> implementation will use some "relative position" semantic internaly is >> an implementation detail. This internal relative position can be >> different for the same set in different hash implementations. > > Yes. The standard doesn't specify the order in which elements (of a > hashed container) are delivered via iterators, so different > implementations can vary. (Among other things, implementations can > vary because the standard doesn't specify the hash table load factor.) > > >> > container. For an "ordered" container (Ordered_Sets, Ordered_Maps), the >> > position is determined by the "<" operator for elements. For a "hashed" >> >> This is a confusion. The "<" operator defines relative order, not >> position. > > You say to-MAY-to, I say to-MAH-to. It's the same. > Yes, it is the same, while we are talking in a bar, siping beer and bashing MS. When we are talking about standards - there is a difference. > >> > An iterator (either passive or active) simply enumerates elements in >> > their order as specified by the type of container they're in (either >> >> Exactly! Note also that the natural name for this is "iterator" not >> "cursor". > > You say "chien", I say "dog". It's the same. > Sure it is the same. So why to change? Just to be different?