c++ - Type conversion between const int * and int * const

Question

const int *: The pointer itself is mutable, but the value pointed to is immutable

int * const: The pointer itself is immutable, the value pointed to is variable

Converting const int * -> int * const will report an error

Conversion int * const -> const int * can be done

Semantically speaking, it is easier to understand, but from a formal point of view, both have an immutable quantity. So why is one direction feasible during conversion, but not the other? After thinking about it, it may be because pointers and values ​​are not on the same level, but I don’t know how to make it clear?

Answer 1

Assume that what is discussed here is implicit conversion (similar to static_cast):

The underlying const complies with qualification conversions: the target type must be more qualified. That is, const can only be more but not less.

4.1 Standard conversions are implicit conversions with built-in meaning. Clause 4 enumerates the full set of such conversions.

4.4.1 A prvalue of type “pointer to cv1 T” can be converted to a prvalue of type “pointer to cv2 T” if “cv2 T” is more cv-qualified than “cv1 T”.

The top-level const rules are more complicated. For class types, whether they can be converted depends on the conversion constructor and conversion function. For non-class types, there is no such thing as top-level const conversion. Clause 4 standard conversions say nothing about top-level const.

---

Here we discuss several situations involving top-level const:

Expression:

5.8 [...] [Note: Because cv-qualifiers are removed from the type of an expression of non-class type when the expression is converted to a prvalue, an lvalue expression of type const int can, for example, be used where a prvalue expression of type int is required. —end note]

Assignment:

3.10.1 [...] the built-in assignment operators expect that the left operand is an lvalue and that the right operand is a prvalue and yield an lvalue as the result.

3.10.2 Whenever a glvalue appears in a context where a prvalue is expected, the glvalue is converted to a prvalue; [...]

3.10.4 Class prvalues ​​can have cv-qualified types; non-class prvalues ​​always have cv-unqualified types.

Initialization:

8.5.16 [...] [ Note: An expression of type “cv1 T” can initialize an object of type “cv2 T” independently of the cv-qualifiers cv1 and cv2. [...]

That is to say, when what is required is prvalue, there is no const prvalue. Regarding glvalue, there are the following conventions:

4.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).[...] 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 or an rvalue reference to function type (8.3.2), an xvalue if T is an rvalue reference to object type, and a prvalue otherwise. The expression e is used as a glvalue if and only if the initialization uses it as a glvalue.

This paragraph stipulates the value category after implicit conversion. When the result of implicit conversion is prvalue, there is no const; and when the result is glvalue, the target type of conversion must be lvalue reference or rvalue reference. In this case, if the following initialization holds, it can be converted:

T &t = e;
T &&t = e;
const T &t = e;
const T &&t = e;

8.5.3.4 Given types “cv1 T1” and “cv2 T2,” “cv1 T1” is reference-related to “cv2 T2” if T1 is the same type as T2, or T1 is a base class of T2. “cv1 T1” is reference-compatible with “cv2 T2” if T1 is reference-related to T2 and cv1 is the same cv-qualification as, or greater cv-qualification than, cv2.

reference-compatible restricts whether it can be initialized. The rules here are similar to the rules of qualification conversion. In addition, these consts are already underlying consts.

PS: There is a footnote at qualification conversions: "These rules ensure that const-safety is preserved by the conversion.". All implicit const conversions, whether agreed upon or imaginary, are fine as long as they can ensure the safety of const. If a const conversion ensures the safety of const, but cannot be implemented because it violates some other terms, then this is probably a language pill. Funny