Re: Ada OO Mechanism

[Hyman Rosen <hymie@prolifics.com>]

Laurent Guerby <guerby@acm.org> writes:
> I don't know if in C++ you can constrain a template type argument to
> be of a specific class (type and class in the Ada sense).

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

> The Ada OO model guarantees that no dispatch operation will run
> non-existing code (even in case of wild generics), I don't know if
> it's true of the C++ one.

Yes, it's true. There will be either a compile-time or link-time
error if non-exisiting code is referenced. In no case will the
error be delayed to run-time.

> * In Ada, with discriminants you can easily have objects of varying
> size being stack allocated instead of heap allocated.

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

> * I don't know if self referencial types have a C++ equivalent (see
> the Ada rationale for an example of such beast).

struct SelfRef
{
	SelfRef &Me;
	SelfRef() : Me(*this) { }
};

> * You can "statically" create complex objects and elaboration issues
> are correctly handled by the Ada definition, I don't think it's the
> case in C++ (I think you don't know in what order the constructors
> will be called for "static" data in C++, I might be wrong).

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.

> * What happens if a constructor or a destructor (C++ terminology)
> raises an exception is fully specified in Ada, in particular in case
> of a destructor exception, for each object in the scope its destructor
> is given a chance to run, when this is done a big general ooops
> exception is raised. I don't know if it is the case in C++.  This
> applies too to function returning objects called as argument of
> another subprogam.

It's fully specified in C++ as well. When a constructor throws, any
already constructed sub-components are destructed. As scopes are left
in search of an exception handler, all constructed objects in those
scopes are properly destructed. If during this process a destructor
throws an exception unhandled within itself, a special termination
handler is called. C++ cognoscenti have concluded that you should not
throw exceptions from destructors because of this.