Re: Ada OO Mechanism

[Laurent Guerby <guerby@acm.org>]

Hyman Rosen <hymie@prolifics.com> writes:
> No, you can not. There are tricks that can accomplish the test, but
> they are tricks, not basic language features. The C++ approach to
> generics is "if it compiles, it works". 

If I understand the rest of your posting, the C++ approach is "if it
links, it works". You have to wait the linker to complain about
mangled symbols not to be there to have the pleasure of trying to find
out where you messed up your template ;-).

> Instead of restricting a parameter to be of a certain type, you just
> write the template as if the parameter has that type. It may be that
> a different type will support the operations equally well, in which
> case there is no reason to prevent the template from working. I
> understand that this is unpleasant for many people who want to be
> able to say and see exactly what's going on with the code.

Strange, I would say that in Ada you doesn't have to know
"exactly what's going on with the code" inside your generic
to use and compile things, whereas in C++ you have to
see the template code to see if your parameters will
work. That's breaking some abstraction.

In Ada: "if it compiles against the spec it works, regardless of the
implementation". This favour distributed team work, properly
abstracted generic specs and so ease build large reliable stuff.

> In C++ as well. In C++, you use a template parameter -
> 
> template <typename T, int N> struct Array { T a[N]; }
> Array<int,5> ai;
> Array<double,10> ad;
> 
> Ada is somewhat ahead here, though, because (if I'm not mistaken)
> in Ada all the discrminated forms are the same type while in C++
> they're not (i.e., in C++, Array<int,5> and Array<int,6> are
> completely unrelated).

Interesting ;-). Also Ada programmers tend to have big generic
contracts (read lots of template arguments), I think the C++ notation
will tend to be cumbersome if one complex template instanciation type
is used a lot (well, you can #define then ;-).

> For objects at file scope in a single compilation unit (a file),
> constructors are called in top-to-bottom order. For static objects
> within a function, constructors are called the first time the flow
> of control passes through the definition. Order of initialization
> across compilation units is unspecified.

That was my point, unless you put everyting in a big C++ source file
you cannot build statically (at elaboration time in the Ada world)
complex objects implying multiple classes.

BTW, thanks for bringing your C++ expertise on us poor Ada guyes, I
really find your posts insightful on a lot of issues ;-).

--LG