Re: Ada Popularity: Comparison of Ada/Charles with C++ STL (and Perl)

[kevin.cline@gmail.com (Kevin Cline)]

Martin Krischik <krischik@users.sourceforge.net> wrote in message news:<1700922.2nPlMsa4Ny@linux1.krischik.com>...
> Kevin Cline wrote:
> 
> > Martin Krischik <krischik@users.sourceforge.net> 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<char>. I can see that I one day might need
> base_string<wchar_t>, 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 <class T> T parse(std::string s)
{
  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<int>(s);

I agree that this is not as obvious as it should be.