Re: tagged record child: override constructor?

["Hyman Rosen" <hyman.rosen@gmail.com>]

Dmitry A. Kazakov wrote:
> So T and T& are two different types, then why methods of T can be used with
> T&?

Because the language says so.

> Is there a type conversion between them?

No.

> When T is converted to T&, why
> it dispatches to methods of T rather than to ones of T&?

T& has no methods. It dispatches to methods of T and derived classes
because that's what the language says. It's not unlike the way Ada
sometimes gives you an implicit .all on an access type.

> A poor C++ newbie
> asks why the following does not compile:
>
> class T& {}; // Isn't T& a type?

Because T& cannot be used as the name of a class. All classes
are types, but not all types are classes.

> T != T& is useful, you say. Then why T /= T'Class is not? (:-))

Actually, you're right about that and I'm wrong. I still think
that Ada's requirement that tagged types be passed by reference
shows that it was a mistake for the language to try to conceal
the parameter passing mode from the programmer.

> But the actual parameter may have another type. It leaks!

Irrelevant. When the paramater is of a specific class type
and you pass a derived type as an argument, the parameter
simply receives a copy of the base part of the argument.
It's referred to as "slicing". And just as you claim to prefer,
once that happens there is no going back to the derived type.
The parameter is well and truly only of its declared type.

> A copy, really? It is a strange copy, when the actual parameter is of a
> derived type. Your theory leaks.

Nope. No leak. It really is a copy of just that subpart of the
argument. That's why most functions in C++ which take class types
as arguments get them by reference. And of course, the distinguished
calling object itself is passed by reference; it's address becomes
the value of the 'this' keyword in the member function.

> Now you have a difficult job to explain what is a subobject. Which type it
> has. Is it a by-reference or by-copy type, etc. Poor old C++ newbie!

Not difficult at all. When you declare a class, it is either standalone
or it inherits from one or more other classes. A reference to any class
in this inheritance hierarchy may be initialized to refer to an object
of the derived class. (It's slightly more complicated because of access
restrictions and the ability to have a class more than once in the
inheritance hierarchy, but that's details.) Classes in an inheritance
hierarchy are just that - classes. You cannot inherit from anything
else,
so there is no such thing as a base class which is a reference.

> "A type is characterized by a set of values..."

But what is the set of values for a tagged type?
Doesn't it include the values of all possible derived types?
After all, reading 4.6, it certainly seems that I'm allowed
to do view conversions back and forth between base and derived
tagged types. So it looks like I can have something that's
declared as a type 'B' but is really an object of a derived
type 'D', and I can take my 'B'-declared object and view-convert
it into a 'D'-declared object, all the while maintaining the
identity of the object.

> > In C++ the declared type does determine what's going on.
>
> Finally! (:-)) I.e. C++ is not a typed language. What else evidence you
> need?

Huh? I said "does", not "doesn't".

> There is a great difference between not yet implemented things and ones
> which cannot be under any circumstances.

The requirements for view conversion and by-refernce passing
make it seem to me that no Ada compiler will ever implement
your version of things.

> The argument "this" is first converted from B* to A*, then this->A::g() is
> called, then it is converted back to B*.

And when this->A::g() calls f(), it does so by dispatching, regardless
of whether the A::g() call originated in a constructor or not.