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

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

Hi,

> In Ada slices are ad-hoc anonymous types, it is how that should be.
> Because
> if you want to work with array slices in a subprogram, you definitely do
> not want to pass all necessary helper types down there. In Ada you just
> write A(10..I) and the job is done.

    In C++ you may write std::vector(V.begin + 9, V.begin() + I) and this is
also anonymous object which is subvector of another vector V. Or you can
pass only iterators and the job is done better, because there's no copying
of elements and you can operate on any container, not only on a vector.

> [Yes you can get this in C++, I believe you, it is all Turing complete
> after all! (:-))]

:)))

>> 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, 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 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 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. So in this case runtime polymorphism doesn't seem to
me to be more flexible than the template solution...

> 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. Can you specify what do you
mean when saying 'mix them'?

> [To continue the analogy, I'am trying to convince a FORTRAN-IV programmer
> that there could be something beyond REAL*4 and REAL*8. (:-))]

    I feel the same ;-). But of course the point is not to fight and win,
but to learn something. I've already learned a few things from this
discussion :).

Best regards,
Robert