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:35:22 +0200, Robert Kawulak wrote:

>> The problem is fundamental, if vector<A> and vector<B> as
>> types have nothing in common, then it is difficult to write a program
>> which can work with both. It is all about generic programming.
> 
>     But I'm still trying to figure out what problems does this entail (and
> why, in this respect, Ada arrays could be better than all array types in
> C++, which is what this discussion was about).

I didn't say that Ada get it solved. I think that Ada is on the right way
there, while C++ moves in the opposite direction.

> My understanding is that
> vector<A> and vector<B> (or Ada arrays of elements of these types) *must* be
> different types because A and B are different types.

They need not to be. To be honest, in Ada you cannot put a constraint on
array's element type, but you can do it for the index type. For the
discussion, there is no much difference what to constrain/derive from. When
you use a template, say: <int From_Index, int To_Index, class Element>,
then different values of From_Index, To_Index constitute different types of
instances. It is unacceptable. This was solved in Ada 83. It has a notion
of array type which can be constrained (the set of all possible constraints
gives that desired ARRAY types set):

type String is array (Integer range <>) of Character;
subtype Subrange is Integer range 1..20;
subtype Substring is String (Subrange);
   -- String and Substring are related types. You can program for Substring
   -- in terms of String.

Yes, Ada does not have it for array elements. You cannot derive from the
element type and get the array of derived elements a subtype of the array
of element. Neither you can dispatch on subtypes etc. But if you have
arrays you could fix it some day...

> Of course they've got
> some common properties and methods independent on the type of held elements
> like the number of elements, but I don't see any difficulties connected with
> this - all vector classes have the same interface,

This "same interface" is not a language object. It is a fiction, which
cannot be described in language terms independently on its implementation.
So you physically unable to program in terms of this interface. It simply
does not exist. What can you do with vector<>? Operator[] defined on it is
not a function. It is a template function. You cannot call it outside of
another template. That template must in turn have the vector's element type
as a parameter etc.

> so it's easy to write a code that copes with vectors of
> elements of different types.

Really? Write code which reads from the stream a type X (from some defined,
but large set of types) and then returns empty vector<X>.

>     Could you clarify this (or at least give some links concerning generic
> programming issues you are writing about)?

Stepanov? (:-))

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