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

["Robert Kawulak" <tigrisek@interia.pl>]

Hi,

> But why an ordered list should not
> implement an array interface? In my view it should, making the above legal
> for lists.

  I think this is a wrong way - list is not a kind of array to implement its 
interface. But both list and vector are *containers*, and they both have the 
common container interface - and that's why std::for_each and other std lib 
algorithms work on any conatiner (be it std::list, std::vector, C-style 
array or a user-defined type).

>> 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;

  Sorry, my mistake. :-P I didn't know about this...

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

;-)

>>> 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.

  'elements of some class -=#not#=- derived from CElement' - I meant if you
can derive, then there's no problem.

> 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.

  And you see, that's the point. I wrote: 'to make it work', and it's
not as easy as it seems. In order to work with container algorithms and
cooperate with other containers, your wrapper should also implement wrappers
for wrapped type's iterators with wrappers for wrapped type's iterators'
functions... Doesn't look to me like 'a matter of one or two code lines' ;-)

>> 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".

  *container* interface. String is not exactly a vector, but might be
treated similarily to one because of it's container-like 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]);
>   ...
> }

  Wouldn't this do?

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

Regards,
Robert