In article <398f7b$325@engnews2.Eng.Sun.COM> clamage@Eng.Sun.COM writes:
>In article 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).
>
>The ARM does not list, so far as I can tell, converting to an accessible
>base class as a standard conversion. Probably this was an oversight.

 NO. Its NOT an oversight.
>
>The current version of the C++ Committee working paper (20 Sept 1994)
>does list it explicitly as a standard conversion in 4.12, and by
>reference in 13.2.3.1.1 [over.ics.scs]. It also says that a sequence
>of standard conversion and user conversion is allowable in argument
>matching.

 But the WP is WRONG.

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

>>>>> John Max Skaller <maxtal@physics.su.OZ.AU> writes:

>> The ARM does not list, so far as I can tell, converting to an accessible
>> base class as a standard conversion. Probably this was an oversight.

>  NO. Its NOT an oversight.

>> The current version of the C++ Committee working paper (20 Sept 1994)
>> does list it explicitly as a standard conversion in 4.12, and by
>> reference in 13.2.3.1.1 [over.ics.scs]. It also says that a sequence
>> of standard conversion and user conversion is allowable in argument
>> matching.

>  But the WP is WRONG.

Huh?  If you're going to make sweeping statements like this, at least
explain yourself.  I assume you're taking issue with this section:

  4.12  Base class conversion                               [conv.class]

1 An rvalue of type cv D, where D is a class type, can be  converted  to
  an  rvalue  of type cv B, where B is a base class (_class.derived_) of
  D.   If  B  is   an   inaccessible   (_class.access_)   or   ambiguous
  (_class.ambig_) base class of D, a program that necessitates this con-
  version is ill-formed.  The result of the conversion is the  value  of
  the base class sub-object of the derived class object.

This seems somewhat bogus to me, too, now that you mention
it. Unfortunately, I think that this is just a symptom of the WP's
confusion as to how to deal with temporary objects of class type; they have
to exist in memory, so they aren't strictly values, and they can be used as
the object parameter in method calls, but in other respects they're
considered rvalues.  In pass-by-value situations, I assume we want to be
able to pass rvalues of a derived type to parameters of a base type...or
don't we?

Jason

In article <JASON.94Nov6234128@phydeaux.cygnus.com> jason@cygnus.com (Jason Merrill) writes:
>>>>>> John Max Skaller <maxtal@physics.su.OZ.AU> writes:
>
>>> The ARM does not list, so far as I can tell, converting to an accessible
>>> base class as a standard conversion. Probably this was an oversight.
>
>>  NO. Its NOT an oversight.
>
>>> The current version of the C++ Committee working paper (20 Sept 1994)
>>> does list it explicitly as a standard conversion in 4.12, and by
>>> reference in 13.2.3.1.1 [over.ics.scs]. It also says that a sequence
>>> of standard conversion and user conversion is allowable in argument
>>> matching.
>
>>  But the WP is WRONG.
>
>Huh?  If you're going to make sweeping statements like this, at least
>explain yourself.

 I'm sorry: in fact I sort of did -- in a previous post.

>I assume you're taking issue with this section:
>
>  4.12  Base class conversion                               [conv.class]
>
>1 An rvalue of type cv D, where D is a class type, can be  converted  to
>  an  rvalue  of type cv B, where B is a base class (_class.derived_) of
>  D.

 Yes. To the best of my recollection:

 a) the rule was not previously present in the WP or ARM,
 b) there is a core issue raised by Ron Guilmette relating
     to this very question
 c) no vote was taken on the issue

I surmise, perhaps incorrectly, that:

 d) the editor added the text (as he is permitted to)
    as an apparent ommission
 e) the change should have been indicated by an editorial box

The reason I think this change is in error is that it is possible
to convert a Derived object to a Base object by calling the
copy constructor of the Base object: if that copy constructor
has a const reference argument, an rvalue can be converted.

In my opinion, IF:

 a) a copy constructor is declared but is not accessible
 b) a copy constructor is not declared and cannot be generated

THEN no such conversion should be permitted, and further,
IF the argument is an rvalue THEN IF

 c) a copy constructor with a non-const reference parameter
  is declared but not a copy constructor with a
  const reference parameter

THEN the program is also ill formed.

These rules can be DEDUCED from the existing rules excluding
the relevant part of 4.12 indicated above, and the introduction
of an additional rule here is guarranteed to be either redundant
or contradictory.

In this case, the introduction of the relevant part of 4.12
introduces a contradiction rendering the Working Paper inconsistent.

Therefore, as I said, the rule is WRONG.  [IMHO: <grin>]

>This seems somewhat bogus to me, too, now that you mention
>it. Unfortunately, I think that this is just a symptom of the WP's
>confusion as to how to deal with temporary objects of class type; they have
>to exist in memory, so they aren't strictly values, and they can be used as
>the object parameter in method calls, but in other respects they're
>considered rvalues.

 Sigh. Yes. Scott Turner understood it best. An rvalue
is NOT a value: in C or in C++, but a FORMULA for initialising
an object. (I.e: a declarative thing as in FORTRAN: such formulas
are _translated_ into executable code wholistically)

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

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

The ARM does not list, so far as I can tell, converting to an accessible
base class as a standard conversion. Probably this was an oversight.

The current version of the C++ Committee working paper (20 Sept 1994)
does list it explicitly as a standard conversion in 4.12, and by
reference in 13.2.3.1.1 [over.ics.scs]. It also says that a sequence
of standard conversion and user conversion is allowable in argument
matching.
---
Steve Clamage, stephen.clamage@eng.sun.com