Why const for implicit conversion?
After extensive reading of ISO/IEC 14882, Programming language – C++ I'm still unsure why const
is needed for implicit conversion to a user-defined type with a single argument constructor like the following
#include <iostream>
class X {
public:
X( int value ) {
printf("constructor initialized with %i",value);
}
}
void implicit_conversion_func( const X& value ) {
//produces "constructor initialized with 99"
}
int main (int argc, char * const argv[]) {
implicit_conversion_func(99);
}
Starting with section 4 line 3
An expression e can be implicitly converted to a type T if and only if the declaration T t=e; is well-formed, for some invented temporary variable t (8.5). Certain language constructs require that an expression be converted to a Boolean value. An expression e appearing in such a context is said to be contextually converted to bool and is well-formed if and only if the declaration bool t(e); is well-formed, for some invented temporary variable t (8.5). The effect of either implicit conversion is the same as performing the declaration and initialization and then using the temporary variable as the result of the conversion. The result is an lvalue if T is an lvalue reference type (8.3.2), and an rvalue otherwise. The expression e is used as an lvalue if and only if the initialization uses it as an lvalue.
Following that I found the section on initializers related to user-defined types in 8.5 line 6
If a program calls for the default initialization of an object of a const-qualified type T, T shall be a class type with a user-provided default constructor.
Finally I ended up at 12.3 line 2 about user-defined conversions which states
User-defined conversions are applied only where they are unambiguous (10.2, 12.3.2).
Needless to say, 10.2 and 12.3.2 didn't answer my question.
- Can someone shed some light on what effect
const
has on implicit conversions? - Does the use of
const
make the conversion "unambiguous" per 12.3 line 2? - Does
const开发者_如何学Python
somehow affect lvalue vs. rvalue talked about in section 4?
It doesn't really have much to do with the conversion being implicit. Moreover, it doesn't really have much to do with conversions. It is really about rvalues vs. lvalues.
When you convert 99
to type X
, the result is an rvalue. In C++ results of conversions are always rvalues (unless you convert to reference type). It is illegal in C++ to attach non-const references to rvalues.
For example, this code will not compile
X& r = X(99); // ERROR
because it attempts to attach a non-const reference to an rvalue. On the other hand, this code is fine
const X& cr = X(99); // OK
because it is perfectly OK to attach a const reference to an rvalue.
The same thing happens in your code as well. The fact that it involves an implicit conversion is kinda beside the point. You can replace implicit conversion with an explicit one
implicit_conversion_func(X(99));
and end up with the same situation: with const
it compiles, without const
it doesn't.
Again, the only role the conversion (explicit or implicit) plays here is that it helps us to produce an rvalue. In general, you can produce an rvalue in some other way and run into the same issue
int &ir = 3 + 2; // ERROR
const int &cir = 3 + 2; // OK
Per section 5.2.2 paragraph 5, when an argument to a function is of const
reference type, a temporary variable is automatically introduced if needed. In your example, the rvalue result of X(99)
has to be put into a temporary variable so that that variable can be passed by const
reference to implicit_conversion_func
.
精彩评论