Tom Ngo <ngo@tammy.harvard.edu> writes:
>Interesting!  This must be a violation of ARM 8.4.3 [References],
>which states:
>
>    A reference to a plain T can be initialized only with a plain T.
>
>Assuming this rule is intended to apply to the initialization of a
>reference in a constructor, it seems you have uncovered an issue that
>really ought to be addressed in the ARM:  what is that status of a
>constructor with regard to constness?  Should it be made possible, as
>suggested by Jim Adcock <jimad@microsoft.UUCP>, for constructors to be
>specified as const?  If so, how would a const constructor be permitted
>to change data members?

I think rather than enforcing const-ness at constructor time [after
all, a reference to "this" is a completely valid use of a reference,
especially if the reference is a reference to a base type] it might
have to be done at method time.  However, only the link phase has all
the information necessary to resolve the reference [a special flag for
"reference to *this!" or something] and then notice the reference
being used in a non-const way inside a const method.  Note that
special attention would have to be paid to the afore-mentioned
constructors that use references to base classes.  e.g.:

struct base { int i; };

struct derived : base
{ derived();
 base &b;
};

derived::derived() : b(*this) {}

Since 'b' is a reference to a base, its address may not == this,
especially of derived were multiply inherited.  Thus, the linker
cannot simply check the address of the reference for equality with
"this".  Perhaps it might check to see if it is a reference to
something "inside the current object" which would include not only
"this", but any fancy stuff like references to "int"s inside the
class.
     Reid
--
Reid Ellis     1 Trefan Street Apt. E, Toronto ON, M5A 3A9
rae@utcs.toronto.edu        ||  rae%alias@csri.toronto.edu
CDA0610@applelink.apple.com ||      +1 416 362 9181 [work]