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, 12 Jul 2005 16:44:02 -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> <1120834341.499757.133770@g43g2000cwa.googlegroups.com> <1121093867.964444.232420@g14g2000cwa.googlegroups.com> <42d2bc2d$0$20148$9b4e6d93@newsread2.arcor-online.net> <1121134291.379399.79460@z14g2000cwz.googlegroups.com> Subject: Re: GCC 4.0 Ada.Containers Cursor danger. Date: Tue, 12 Jul 2005 16:47:10 -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-P2bMnVAPCNj6F9m/bNyjU1L60GhSOhGbXrZLvnL/RD5vtdqR+YoGCUJEkYWFG9L9WmZPUt+KE3zeapO!z+ENI8uP/XdEu1zMsoQ+N4FwBQg1cvdPgi6w9JxQex1inRyyzBRAX2BwuUvQIKt/z0qSsZt+GsJe 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.32 Xref: g2news1.google.com comp.lang.ada:12033 Date: 2005-07-12T16:47:10-05:00 List-Id: "MMM" wrote in message news:1121134291.379399.79460@z14g2000cwz.googlegroups.com... > Georg Bauhaus wrote: ... > > First, Ada.Containers is not trying to approximate some notions > > from linear algebra ("orthogonal normal basis"), metaphorically > Note that this notion is not limited to linear algebra and I'm not > agitating > for implementation of this notion in Ada.Containers in any way! > ;):);):) > What I've ment is that library should implement all commonly used and > accepted abstractions and then, if it is practical, implement all > needed specialisations, mixtures, etc. Ada.Containers does implement the widely-used abstractions (Vectors, Lists, Sets, Maps), and a number of flavors of each. What it doesn't try to do is implement *every* possible abstraction; there isn't enough manpower to do that. Especially nearly useless ones like unordered maps and sets. If you think that unordered sets and maps are useful, go ahead and design some (you'll find they fit it the design very well). ... > Actually current proposal have to justify the use of such a > wonderful abstractions as Ordered_Sets, Hashed_Sets, Hashed_Maps and > Ordered_Maps as a basic set of abstractions. We don't; they're not "basic" abstractions. They're *useful* abstractions. We hope that in the future a fuller library is built around this one. ... > > Indeed, a close correspondence of order and choice of container > > will defeat some generic algorithms. > Care to provide an example of such a generic algorithm? If your > algorithm is so generic that order and access details are not > important, then express you algorithm in terms of Abstract_Collection. > Then averyone could choose any collection type that fits the task > in question most. We didn't define an abstract collection because it doesn't work with the generic design of the libraries. And you have to know the element type in order to do anything useful. One idea that was considered was a number of signature generics that provided such a generic container. But there is a problem with Ada that we were not able to solve that prevents such generics being declared in the containers packages. So we decided to leave that also for a future standard. ... > The sad thing is that this proposal > forces the whole Ada comunity to learn the hard way and to reinvent > collections from scratch. Take a look at others languages collections > implementations. We did. Remember that the entire Ada community was involved with this design; there are literally hundreds of comments on the library, many of which caused significant changes to it. The truly sad thing is that *you* didn't participate in that discussion (which has been going on for years, including here). Now that the standard is getting its final polishing, someone jumps in and says "I don't like it!". Sorry, but we're not going to start over because one person who didn't even pay any attention doesn't like it. And let me make it very clear -- no one is completely happy with this library. Everyone has something that they would do different. That's a typical reaction to something that is understood by everyone. The benefit here is having something standard. What exactly it is doesn't matter much. It is very similar to the situation with Unbounded_Strings. That library is designed about as incorrectly as possible, but it still gets wide use, and it still is very valuable to Ada programmers. The exact details don't matter. > >> Another silliness is overgeneralization of the > >> 'iterrator' concept and renaming it to 'cursor'. We certainly don't have to repeat mistakes made in other libraries! An iterator is something that actively moves from element to element. There is no possible way for a piece of data alone to be an iterator. One could argue that the combination of the cursor object and the Next function compose an iterator, but not the separate pieces. We selected the name "cursor" because it didn't have the baggage of "reference" or "designator". A cursor is a designator to an element in a container. Period. Yes, you can use it for iteration, but that is just one of the possible uses for it (and not a particularly important one, IMHO). > Authors of this proposal stated that > they model their library on STL. So why to name the same thing > differently? Because the STL got it wrong. And, in any case, our terminology has to match that of Ada, not that of C++. If we're just copying C++, there is no reason to bother - we might as well just turn out the lights here in Adaville. ... > It looks like the authors of this proposal didn't have a > goal of creating clear and solid foundation for future library development. That was a secondary goal at best. I think we did a fine job of that, but only attempts to add units to the containers library will show that for sure. > It looks like they provided just a bunch of special case algorithms and > abstractions using far from perfect terminology. No, we took a minimalist approach and defined only the containers that are widely needed. That means some of the basic abstractions (which are not going to be used much) are left out. > To understand this one need > no degree in mathematics, just look around - STL,Java,Python, etc.,etc. Those libraries are far larger, and for the most part, far less rigourously defined. Most are defined by an implementation rather than a standard. If we had an unlimited budget, I'm sure that many more containers would have been included. But we don't have an unlimited budget or unlimited time. Randy Brukardt.