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=-0.9 required=5.0 tests=BAYES_00,FORGED_GMAIL_RCVD, FREEMAIL_FROM autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,243dc2fb696a49cd X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII Path: g2news1.google.com!postnews1.google.com!not-for-mail From: kevin.cline@gmail.com (Kevin Cline) Newsgroups: comp.lang.ada Subject: Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) Date: 28 Sep 2004 20:04:59 -0700 Organization: http://groups.google.com Message-ID: References: <1777528.JKnUEYTOM6@linux1.krischik.com> <1ec946d1.0409230820.455ad242@posting.google.com> <3673998.bj16mkkOu2@linux1.krischik.com> <1700922.2nPlMsa4Ny@linux1.krischik.com> <1636756.M7hCqjsVMv@linux1.krischik.com> NNTP-Posting-Host: 170.215.185.70 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Trace: posting.google.com 1096427100 2463 127.0.0.1 (29 Sep 2004 03:05:00 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Wed, 29 Sep 2004 03:05:00 +0000 (UTC) Xref: g2news1.google.com comp.lang.ada:4356 Date: 2004-09-28T20:04:59-07:00 List-Id: Martin Krischik wrote in message news:<1636756.M7hCqjsVMv@linux1.krischik.com>... > Kevin Cline wrote: > > > Martin Krischik wrote in message > > news:<1700922.2nPlMsa4Ny@linux1.krischik.com>... > >> Kevin Cline wrote: > >> > >> > Martin Krischik wrote in message > >> > news:<3673998.bj16mkkOu2@linux1.krischik.com>... > >> >> Matthew Heaney wrote: > >> >> > >> >> > If AI-302 doesn't meet your needs, then you need to let us know. > >> >> > Please peruse the a-c*.ad[sb] sources at the tigris website.��(Note > >> >> > that I'm still incorporating changes from the most recent ARG > >> >> > meeting.) > >> >> > >> >> I have got my most important baby (indefinite types). And I don't want > >> >> to confuse the ARG. I fully agree that we need a container library > >> >> inside the standart. > >> >> > >> >> However it would be sad if Ada.Containers would kill off all other > >> >> container libraries. Just like the STL did. > >> > > >> > I think the STL killed off all the other container libraries because > >> > the STL container/algorithm separation is an extremely powerful design > >> > that dominates all older container library designs. Certainly STL > >> > programming is much cleaner and easeir than programming with the once > >> > popular RogueWave containers. The STL also has the advantage that it > >> > is relatively easy to write new containers that will work with the STL > >> > algorithms, so that even though new containers are written, they all > >> > look like STL containers. > >> > >> No Library is perfect, but the "I which I had" list for the STL is much > >> larger then for container out of IBM's OCL. The OCL was not designed for > >> academic correctness bit but for usability. > >> > >> >> Im am sill looking at IBM OCL thinking > >> >> how much more practical it was. std::string might me academicly > >> >> correct but IString was a lot more usefull in day to day live with all > >> >> the asInt (), asUnsigned (), asAnythingYouEverNeed() methods. > >> > > >> > The problem with that design is that it isn't readily extensible to > >> > accomodate user-defined types, and it makes generic programming very > >> > difficult. > >> > >> In 99.99% of all cases I don't need strings on user defined types. I need > >> base_string. I can see that I one day might need > >> base_string, but I have not until now. They made all that funky > >> design which I just never need. > > > > That wasn't the sort of extensibility I was thinking of. I was > > referring to > > the inextensibility of the series of member functions asInt(), > > asUnsigned(), etc. Collections of functions with names varying > > according to the return type inhibit template programming. If you > > want to be able to conveniently extract values from a string, you can > > write this template function: > > > > template T parse(std::string s) > > thow (something) > > > { > > T result; > > stringstream strm(s); > > strm >> result; > > if (!strm) throw( /* something */ ); > > return result; > > } > > > > and then you can write: > > std::string s("10"); > > int i = parse(s); > > This is indeed cool. And it tells me that my code is missing a throw. Yes, and if you define a new type, say MyType, then you just have to implement: istream& operator>>(istream& i, MyType& mt) { ...; return i; } and then you can write: MyType mt = parse(s); Since the input and output for all types is handled identically, generic programming is easy. I once wrote a small set of template classes to map relational database columns to object fields, like this: struct Person { SocialSecurityNumber ssn; Date birthDate; std::string firstName; ... } DatabaseMap personMap; personMap .insert("PERSON", "SSN", &Person::ssn) .insert("PERSON", "DOB", &Person::dateOfBirth) .insert("PERSON", "FIRST", &Person::firstName) ...; personMap.Insert(someone); databaseCursor = // some query //; personMap.Read(databaseCursor, someone); someone.firstName = "Fred"; personMap.Update(someone); ... This would have been completely unwieldy in Ada for two reasons: 1. There would have been dozens of complex instantiations of insert. 2. AFAIK, Ada does not support pointer-to-record member so it would have been necessary to somehow wrap each record member with a function.