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

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Sun, 3 Oct 2004 21:53:32 +0200, Robert Kawulak wrote:

>>> std::for_each algorithm and the like... (especially useful with
>>> boost::lambda)
>>
>> In Ada:
>>
>> for Index in A'Range loop
>>   ...
>> end loop;
>>
>> Here the iterator type and its constraint are constructed out of the
>> object. Feel the difference!
> 
>     The only case where Ada is less verbose than C++ ;-) But on the other
> hand you cannot do this with a list, a map, a deque,

It is because they are not arrays. But why an ordered list should not
implement an array interface? In my view it should, making the above legal
for lists.

> nor you can do the following so concisely:
> 
> std::vector V(10);
> 
> // Apply SomeFunction to elements [4, 9] in reverse order:
> std::for_each(V.rbegin() + 1, V.rend() - 3, SomeFunction);

for Index in reverse V'First + 4..V'Last loop
   SomeFunction (V (Index)); -- Better to place its body here, if short
end loop;

> For instance (using boost::lambda) print those elements:
> 
> // Print elements [4, 9] in reverse order:
> std::for_each(V.rbegin() + 1, V.rend() - 3, std::cout << _1);
> 
> Feel the difference! ;-)

I do! I hate implicit iterators, I prefer loops where possible. Especially,
because exit conditions, nested iterations, exception handling become
visible.

[ Ranting: 40 years spent in developing readable, safe, well-structured
language constructs, only to replace them with nested function calls a la
Lisp? ]

>>> I see your point. When designing containers in std library, its creators
>>> had
>>> two possibilities to choose from:
>>> 1. Make all the containers polymorphic,
>>> 2. Make all the containers use consequent naming of members and make all
>>> the
>>> algorithms templated.
>>> They have choosen 2, because it's far more efficient (no virtual calls,
>>> many
>>> bindings resolved at compile time and even inlined) and far more
>>> flexible.
>>
>> Far less flexible you mean.
> 
>     C++ doesn't have a single-rooted object hierarchy. So if containers
> weren't templates, they'd have to contain elements of some abstract class,
> call it CElement. Now, if you want to have a container of elements of some
> class not derived from CElement or even a container of int, then you'd have
> to make some wrapper classes - this would cost you a lot of time to make it
> work with the library.

Yes, unless:

1. (for new types) language supports multiple interface inheritance. C++
does, Ada 2005 will.

2. (for existing types) language supports supertyping. If it does, then
creating a wrapper will be a matter of one or two code lines. You create a
helper type which is both a subtype of CElement and a supertype of int.

> So in this case runtime polymorphism doesn't seem to
> me to be more flexible than the template solution...

Formally it is more flexible and powerful. The problem is that OO languages
like C++ and Ada are much too much concentrated on generics, which are a
dead end IMO, instead of investing more efforts in better ADT.

>> No you cannot, when you have to mix them. If your program needs both
>> vector<char> and string (to copy a part of one into another) then you have
>> to parametrize it twice with two types. Now consider what happens if there
>> are 100 different, yet related types?
> 
>     Nothing happens. ;-) If you have a function template copying elements of
> one container into another, then it'll work fine even for 100 container
> types, as long as they use the same interface.

Which interface you mean? string is an instance of another template. It is
not vector<>, and there is no way to make it conform to vector<>, because
there is no such thing as "vector interface".

> Can you specify what do you mean when saying 'mix them'? 

All cases were:

template <class A, class B> Foo (vector <A>& X, vector <B>& Y)
{
   ...
   Do_Something (X [I], Y [J]);
   ...
}

cannot be replaced with:

template <class A> Foo (vector <A>& X, vector <A>& Y)
{
   ...
   Do_Something (X [I], Y [J]);
   ...
}

Technically, you have to factor vector<> out of vector<A>, vector<B>, etc.
When you do, that will be the ARRAY.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de