Open
Description
[class.cdtor] p2 needs a note to clarify its limitations.
Bugs which lead back to this paragraph
GCC contributers have falsely interpreted this paragraph to mean that this
can be marked __restrict
. See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82899. A more detailed explanation for why this reading is incorrect can be found here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110912.
Proposed Solution (1/2)
- I think the wording should be made more conventional, by using the term "value computation" instead of saying "the value ... thus obtained".
- Only scalar type objects can be accessed [defns.access] Note 1, so any object which has subobjects cannot be accessed.
During the construction of an object, if the value of
-the object or
any of its subobjects is accessed through a glvalue that is not obtained, directly or indirectly,
from the constructor's this pointer,
-the value of the object or subobject thus obtained is unspecified.
+the value computation of this subobject yields an unspecified value.
Proposed Solution (2/2)
Furthermore, it may be beneficial to add a note which clarifies that a side effect on the subobjects through such a glvalue will have the expected effect. The attached example could also include a case such as:
struct S {
int x;
S(int &r) {
r = 0; // if r refers to S::x, then this is equivalent to x = 0
}
};
S s(s.x);
Activity
frederick-vs-ja commentedon Aug 8, 2023
I think it's almost clarified that non-scalar objects can be accessed, although they must be accessed via scalar glvalues, see #4777.
Eisenwave commentedon Aug 8, 2023
Related: https://cplusplus.github.io/CWG/issues/2271.html. This issue removed the "const object" restriction for the paragraph, however, in its current state, it still isn't strong enough to imply
__restrict
.Eisenwave commentedon Aug 8, 2023
I see, in that case, part 1 could be limited to: