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:<1636756.M7hCqjsVMv@linux1.krischik.com>...
> Kevin Cline wrote:
> 
> > 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)
> 
>      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<int>(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<MyType>(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<Person> 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.