Open xmh0511 opened 2 years ago
I think we should say evaluation of something and/or binding reference to some out-of-lifetime object results in undefined behavior.
If stricter restrictions are wanted, we may say evaluation of
yobj.x
in the posted example), orresults in UB.
It should be unnecessary to talk about a pointer to member subobject as it must be obtained from a glvalue.
But perhaps we shouldn't additionally specify UB here except for conversions involving a virtual base classes (see also CWG1517). I guess out-of-lifetime member access &yobj.x
should be OK - it's unclear why the triviality of constructors/destructors is in effect.
Full name of submitter (unless configured in github; will be published with the issue): Jim X
[class.cdtor] p1 says
Consider a case that lakes to specify in the example, which would help to comprehension the meaning of "referring to"
Is the
id-expression
(x) considered as "referring to" the non-static data memberx
of the objectY
?Suggested resolution
If the "referring to" does not intend to cover the above case, [class.cdtor] p1 will be clear if it is changed to
This is clear that, in the above case,
#1
does not result in undefined behavior since theglvalue
(yobj.x.i
) refers to the member subobject of the member subobjectx
ofyobj
where the objectx
's class has the trivial constructor. The same is true for the pointer value that results from the glvalue.