🚀 go-pugleaf

jpotter@falcon.lhup.edu (John E. Potter) writes:

>The following produced interesting results on several compilers.  I am not
>using the compilers to interpret the DWP, but am trying to use the DWP to
>justify the compilers and predict the future.  None of these compilers
>support the four new specific casts; however, I will try to explain their
>actions in terms of them.  The question involves the first item following
>return in fun.  I believe the += disambiguates to an expression statement.
>
>struct I1 {
>	I1 (int v) : x(v) { }
>	I1& operator+= (const I1& rhs) { x += rhs.x; return *this; }
>	int x;
>	};
>struct I2 {
>	I2 (int v) : x(v) { }
>	I2 (const I2& src) : x(src.x) { }
>	I2& operator+= (const I2& rhs) { x += rhs.x; return *this; }
>	int x;
>	};
>int nofun (const int& s) { return (int&)(s) += 10; }
>int fun (const int& s) { return int(s) += 10; }
>I1 fun (const I1& s) { I1 t(10); return I1(s) += t; }
>I2 fun (const I2& s) { I2 t(10); return I2(s) += t; }
>
>		  comp1            comp2            comp3            comp4
>nofun     const_cast<int&> const_cast<int&> const_cast<int&> const_cast<int&>

The compilers are all correct here.

>fun(int)  const_cast<int&> static_cast<int> static_cast<int> static_cast<int>
>          *****            error lvalue     error lvalue     error lvalue

Compiler `comp1' is wrong.  The other compilers are correct.
The invocation of `+=' is illegal here, because 5.17[expr.ass]/1
requires that the left-hand operand be an lvalue, and `int(s)' is not
an lvalue.

>fun(I1)   static_cast<I1>  const_cast<I1&>  static_cast<I1>  static_cast<I1>
>          no error         *****            no error         error lvalue

Compiler `comp2' is wrong.  The other compilers are correct.

5.17[expr.ass]/1 does not apply in this case, because `+=' here
refers to an overloaded operator, not the built-in version.
In this case, `+=' is a member function, and it is OK for the
left-hand operand to be a non-lvalue.

Some people might argue that 12.2[class.temporary] allows the behaviour
of `comp2', but if that is true, it is a problem in the wording of 12.2 -
I think the intent is definitely that `I1(s)' should be required to make
a copy of `s'.

>fun(I2)   static_cast<I2>  static_cast<I2>  static_cast<I2>  static_cast<I2>
>	   no error         no error         no error         no error

Again, no problems here -- all the compilers are correct.

>When I originally wrote fun, my intent was to create an unnamed temp and
>return a modification of it.  This requires the use of a copy constructor
>and I was surprised to find that I got different results when I wrote it
>and when I let the compiler implicitly provide it.

As I said above, I think this is a bug in `comp2'.

>fun(I2) gave me what
>I wanted and has been permitted by many compilers.  If I read the DWP
>correctly, constructors return rvalues and it is now illegal.

You don't read it correctly.  Constructors return rvalues, but a call
to a member function does not require an lvalue, even if that member
function is `operator +='.

>Does an explicitly written copy constructor with
>the same semantics as the implicit one have different meaning?

No.

--
Any mail to me between Feb 24th and 27th may have gone to the bit bucket
(#&$^@$!# mail software silently ignored disk full error).  Please resend.
(comp.std.c++ articles were not affected, so no need to resend those.)
Fergus Henderson             	WWW: http://www.cs.mu.oz.au/~fjh
fjh@cs.mu.oz.au              	PGP: finger fjh@128.250.37.3
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your 
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu 
]