Overloading reference operator

[James Kanze]

On May 11, 11:56 am, samjam86 <[email protected]> wrote:

[...]

The result of the implicit conversion operator can't be used
as an l-value, unfortunately (major language flaw, IMO).

What would it mean for it to be an l-value. Roughly speaking,
an l-value is something that has an address. What is the
address of an implicit conversion of int to double?

In the actual example, the problem was initializing a reference
to a non-const with an rvalue. This was allowed in early C++;
it was banned because it caused too many unintentional errors,
e.g.:

void incr(int& i) { ++ i; }

int
main()
{
unsigned x = 42;
incr(x);
std::cout << x << std::endl;
return 0;
}

This program output 42. (It's now illegal, but the first C++ I
used allowed it.)

 

[James Kanze]

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 it anywhere in section [12.3.2].

§4/3: "[...] The result [of an implicit conversion] is an lvalue
if T is a reference type, and an rvalue otherwise."

This is also true for explicit conversions.

 

[James Kanze]

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 it
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 other
types in several contexts:
? When used as operands of operators. The operator?s requirements for its
operands dictate the destination type (clause 5).
...

a) [4/2] is a non-normative note.

§4/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 §5, 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
§5.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 (§13.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].