Re: Initialization of reference from implicitly-converted
unrelated type
On 2011-10-17 23:52, nikkoara wrote:
I am inclined to believe the following is a compiler error. Any
opinions?
$ g++ --version | head -n 1; cat -n t.cpp; g++ -c t.cpp
g++ (GCC) 4.6.1
1 struct B { };
2 struct D : B { } d;
3
4 struct X { };
5 struct Y : X {
6 Y (D const&);
7 };
8
9 X const& ref = d;
t.cpp:9:16: error: invalid initialization of reference of type ?const
X&? from expression of type ?D?
This is ill-formed according to C++03, because none of the bullets of
8.5.3 [dcl.init.ref] p5 (reference initialization) applies. Once you
have an lvalue of D, only a conversion function (not a converting
constructor) from D to Y or X could be considered. C++11 has some
wording in 8.5.3 p5 b2.1.2 which looks as if it /could/ apply:
"? Otherwise, the reference shall be an lvalue reference to a
non-volatile const type (i.e., cv1 shall be const),
[..]
? If the initializer expression
[..]
? has a class type (i.e., T2 is a class type), where T1 is not
reference-related to T2, and can be implicitly converted to an xvalue,
class prvalue, or function lvalue of type ?cv3 T3?, where ?cv1 T1? is
reference-compatible with ?cv3 T3?,
then the reference is bound to the value of the initializer expression
in the first case and to the result of the conversion in the second case
(or, in either case, to an appropriate base class subobject).[..]"
but this contradicts to 13.3.1.6 [over.match.ref]:
"Under the conditions specified in 8.5.3, a reference can be bound
directly to a glvalue or class prvalue that is the result of applying a
conversion function to an initializer expression. [..]"
This only allows conversion *functions* (not constructors) to be
considered here.
It has already been recognized that the C++11 wording is defect here, as
shown by
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1287
The currently suggested wording would clarify that [over.match.ref] is
relevant here. The wording suggestion of #1287 will probably require
some further refinements (strike of "class prvalue" in 8.5.3 p5 b2.1.2)
because of other inconsistencies of the current state, but these are
unrelated to your example.
This slightly changed version compiles:
$ g++ --version | head -n 1; cat -n t2.cpp; g++ -c t2.cpp
g++ (GCC) 4.6.1
1 struct X { };
2 struct Y : X { };
3
4 struct B { };
5 struct D : B {
6 operator Y();
7 } d;
8
9 X const& ref = d;
Well, this example is *not* slightly changed! This example is
well-defined, because a conversion *function* exists from D to Y. In
C++03 this ended in the last bullet of 8.5.3 p5 and this will happen in
C++11 as well (especially after clarification by #1287).
These (intended) rules have the important advantage, that the conversion
rules are quite stable, independent from other type definitions that
might be included. If the first example were well-formed, this would
have the effect that a converting constructor of a completely unrelated
type (like Y in the first example) would allow a very indirect
conversion. This would also impose rather strong requirements on
compilers because they would be required to look at *every* type that
could potentially be a derived class of X. With the current rules, this
is much simpler: The compiler has only to look into D and its base
classes to look for a conversion function that could match here.
HTH & Greetings from Bremen,
Daniel Kr?gler
--
[ See http://www.gotw.ca/resources/clcm.htm for info about ]
[ comp.lang.c++.moderated. First time posters: Do this! ]