The example in [conv.qual]/1 says that the type const int **
has two cv-decompositions.
A cv-decomposition of a type T is a sequence of cv_i and P_i such that T is
“cv_0 P_0 cv_1 P_1 ⋯ cv_{n−1} P_{n−1} cv_n U”
for n≥0, where each cv_i is a set of cv-qualifiers ([basic.type.qualifier]), and each P_i is “pointer to” ([dcl.ptr]), “pointer to member of class Ci of type” ([dcl.mptr]), “array of N_i”, or “array of unknown bound of” ([dcl.array]). If P_i designates an array, the cv-qualifiers cv_{i+1} on the element type are also taken as the cv-qualifiers cv_i of the array. [ Example: The type denoted by the type-id
const int **
has two cv-decompositions, taking U as “int
” and as “pointer toconst int
”. — end example ] The n-tuple of cv-qualifiers after the first one in the longest cv-decomposition of T, that is, cv_1,cv_2,…,cv_n, is called the cv-qualification signature of T.
Why the type does not have three decompositions, the third one with n=0, cv_0 empty and U="pointer to pointer to const int
"?
Why the type does not have three decompositions
It has, but the example is slightly out of sync with the normative part. The normative wording was changed relatively recently by this commit replacing the condition in the definition of cv-decomposition from n > 0
to n ≥ 0
.
The PR fixing the issue in the example is here.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With