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.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC 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!news2.google.com!proxad.net!newsfeed.stueberl.de!newsfeed.r-kom.de!newsfeed00.sul.t-online.de!newsmm00.sul.t-online.de!t-online.de!news.t-online.com!not-for-mail From: Martin Krischik Newsgroups: comp.lang.ada Subject: Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl) Date: Tue, 28 Sep 2004 09:51:25 +0200 Organization: AdaCL Message-ID: <1636756.M7hCqjsVMv@linux1.krischik.com> References: <1777528.JKnUEYTOM6@linux1.krischik.com> <1ec946d1.0409230820.455ad242@posting.google.com> <3673998.bj16mkkOu2@linux1.krischik.com> <1700922.2nPlMsa4Ny@linux1.krischik.com> Reply-To: krischik@users.sourceforge.net Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Transfer-Encoding: 8Bit X-Trace: news.t-online.com 1096359667 01 11902 jO9jX0E69vR4nAz 040928 08:21:07 X-Complaints-To: usenet-abuse@t-online.de X-ID: V9xr4UZ-oeOOOoGjGgMg7S31lKTF74FLpU4HhoQv6pWYuoVrCJhbcy User-Agent: KNode/0.8.0 Xref: g2news1.google.com comp.lang.ada:4313 Date: 2004-09-28T09:51:25+02:00 List-Id: 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. I wonder how many programmers still use C's itoa for the job. And of those who do use stringstream how many forgot to check the result. > I agree that this is not as obvious as it should be. It should be part of the standart. The algorithm section contains all sorts of search, sort, stack and whatever else algorithm - but no string parsers. Stack algorithms are < 10 lines as well. With Regards Martin -- mailto://krischik@users.sourceforge.net http://www.ada.krischik.com