In article <394lfi$ob4@Mercury.mcs.com> tmoog@MCS.COM (Thomas H. Moog) writes:
>
>There appears to be no discussion in the draft standard (or the ARM)
>of slicing as one of the possible methods of converting an object of a
>derived class to a base class *during argument matching* (in order to
>select an overloaded function).  I'm NOT referring to the standard
>conversion of a pointer/reference to a derived class to a
>pointer/reference to a base class which is discussed.
>
>The g++ compiler (2.5.8) does not allow slicing to be combined with a
>user-defined conversion/operator function, but cfront does, sometimes.
>
>Is argument matching by slicing a "standard conversion", a
>"user-defined" conversion, or some other kind of beast.  Is this
>specified someplace, or implementation dependent as it appears to be.

 Is copy construction a conversion?

 Consider: there IS a standard conversion

 Derived const& --> Base const&

Now, all you need to slice an object is to call its base class
copy constructor and bind its parameter using the above upcast.
So: IMHO slicing is NOT a standard conversion per se, but you
there is no way to tell that it isnt if copy constructors
are ignored during overloading.

 f(Base); Derived d;
 f(d);

We don't need slicing to be a standard conversion to account
for what happens here: call

 Base::Base(const Base&);

with the parameter bound to d via the reference upcast.


--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,
        81A Glebe Point Rd, GLEBE   Mem: SA IT/9/22,SC22/WG21
        NSW 2037, AUSTRALIA     Phone: 61-2-566-2189

> Is argument matching by slicing a "standard conversion", a
> "user-defined" conversion, or some other kind of beast.  Is this
> specified someplace, or implementation dependent as it appears to be.

For example:

struct B { int b; };
struct D : public B { int d; };

void g(B);

void f(D d) { g(d); }

The call 'g(d)' is legal because 'd' can be converted to a 'B' by the implicit
'B::B(const B&)'.  This qualifies as a "user-defined" conversion.  If the user
had defined a private 'B::B(const B&)','g(d)' would be illegal.
       --scott

>>>>> scott douglass <scott@newton.apple.com> writes:

>> Is argument matching by slicing a "standard conversion", a
>> "user-defined" conversion, or some other kind of beast.  Is this
>> specified someplace, or implementation dependent as it appears to be.

> For example:

> struct B { int b; };
> struct D : public B { int d; };

> void g(B);

> void f(D d) { g(d); }

> The call 'g(d)' is legal because 'd' can be converted to a 'B' by the
> implicit 'B::B(const B&)'.  This qualifies as a "user-defined"
> conversion.

Copy constructors are not considered user-defined conversions under the new
overloading rules; they are considered lvalue->rvalue conversions, which
are included under the "exact match" category.

Jason

There appears to be no discussion in the draft standard (or the ARM)
of slicing as one of the possible methods of converting an object of a
derived class to a base class *during argument matching* (in order to
select an overloaded function).  I'm NOT referring to the standard
conversion of a pointer/reference to a derived class to a
pointer/reference to a base class which is discussed.

The g++ compiler (2.5.8) does not allow slicing to be combined with a
user-defined conversion/operator function, but cfront does, sometimes.

Is argument matching by slicing a "standard conversion", a
"user-defined" conversion, or some other kind of beast.  Is this
specified someplace, or implementation dependent as it appears to be.

Tom Moog