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!news4.google.com!news.glorb.com!hwmnpeer01.lga!hwmedia!hw-filter.lga!fe06.lga.POSTED!53ab2750!not-for-mail From: Mikhail Terekhov User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: GCC 4.0 Ada.Containers Cursor danger. References: <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> <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> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Message-ID: X-Trace: dkoicekneficefklghnlijioinbameidplihkjbjpnhoagomlkofpbhdcomdnfbnjbpgffabkfbgngnifipihpcpekfjbnfkidfplajgfgcdgmajnkpknjbmondpckckbcfagklmibllijll NNTP-Posting-Date: Wed, 13 Jul 2005 22:01:22 MST Date: Thu, 14 Jul 2005 01:01:23 -0400 Xref: g2news1.google.com comp.lang.ada:3620 Date: 2005-07-14T01:01:23-04:00 List-Id: Randy Brukardt wrote: > "MMM" wrote in message > news:1121194262.036046.38230@g49g2000cwa.googlegroups.com... > >>I agree with you completely. The problem is that Matthew insist that >>there is no need for plain >>vanilla unordered set and/or plain vanilla unordered hash, they do not >>even exist in computer science >>and the basis of the Ada.Containers library should form Ordered_Set and >>Ordered_Hash. > > > You seem to be confused about the purpose of the Ada.Containers library. It > is provide the most useful containers in the standard fashion. It's not to > be complete in any way. The names and design of containers was specifically > selected to make it easy to add other containers in the future, like > unordered sets and maps, bounded forms, protected forms, and the like. That is not completely true. Current proposal explicitly oriented on some special case - ordered containers. The point that sorted containers are the most useful is questionable. There are a lot of applications where order is not relevant. > > One of the first things that we did was to discard pure unordered sets and > maps to reduce the size of the library. (It's now about the maximum size > that we could define.) The reason has that for virtually all needs, an > ordered set or map will suffice. The performance characteristics are > similar, the overhead is not significant in most applications, the > operations are a superset, so they are good enough. The reverse is clearly > not true (if you need ordering, it can't reasonably be simulated with an > unordered set or map). The problem is that ordered sets and maps are so special that when you need them in your application it instantly brings a question - is this application is really so special or is there some kind of deficiency in design. > > Clearly, the library could have lots of other kinds of containers, but these > are going to be used much less often than the ones defined. We hope that a > secondary standard is created down the road for such containers; Of course the missing containers will never be used :) > 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. > hope that it focuses future work so that we have more similar components > rather than a plethora of different designs. It's not going to be the > perfect design for everyone (probably, in fact, no one will think it to be > perfect), but as a standard, it will always be available to Ada users. > Somewhat agree. Mikhail