Re: Overloading reference operator
On May 14, 9:10 am, Kai-Uwe Bux <jkherci...@gmx.net> wrote:
cpp4ever wrote:
On 05/14/2010 01:28 AM, Kai-Uwe Bux wrote:
sebastian wrote:
[...]
The result of the implicit conversion operator can't be used as an l-
value, unfortunately (major language flaw, IMO).
Could you provide the clause in the standard for that? I didn't find i=
t
anywhere in section [12.3.2].
try section 4 paragraph 2, this deals with when implicit conversions
will be attempted.
If read:
[Note: expressions with a given type will be implicitly converted to ot=
her
types in several contexts:
? When used as operands of operators. The operator?s requirements for i=
ts
operands dictate the destination type (clause 5).
...
a) [4/2] is a non-normative note.
=A74/3, just below it, is normative.
b) From context, it might just talk about standard
conversions, which only apply to built-in types.
It does just talk about standard conversions. Other conversions
require calling a constructor or a function. You'll find the
appropriate text in =A75, I think. (But it would be nice if the
standard were clearer that this applies even when the function
call or type conversion operator is implicit, and not explicitly
written.)
c) From the beginning that I quoted, it seems clear that
operator=, just like other operators, can trigger an implicit
conversion.
Yes. On the right side, there's no problem. On the left side:
-- If the target type is a built-in type, then the rules in
=A75.28 require an lvalue. The result of a built-in
conversion isn't legal.
-- If the target type is a class type, then operator= is a
member function, and obeys the rules of member function
overload resolution, in particular (=A713.3.1/5) "no temporary
object can be introduced to hold the argument for the
implicit object parameter" and "no user-defined conversions
can be applied to achieve a type match with it".
As for something like:
struct Toto { operator int&(); };
Toto t;
t = 42;
, I don't know whether overload resolution should find it or
not.
d) There seems to be nothing about l-values in [4/2].
It's probably a typo for [4/3].
--
James Kanze