问题
The N4778 draft (2018) of the C++ standard contains the following section:
7.2.1 [basic.lval]
If a program attempts to access the stored value of an object through a glvalue of other than one of the following types the behavior is undefined:
- the dynamic type of the object,
- a cv-qualified version of the dynamic type of the object,
- a type similar (as defined in 7.5) to the dynamic type of the object,
- a type that is the signed or unsigned type corresponding to the dynamic type of the object,
- a type that is the signed or unsigned type corresponding to a cv-qualified version of the dynamic typeof the object,
- an aggregate or union type that includes one of the aforementioned types among its elements or non-static data members (including, recursively, an element or non-static data member of a subaggregate or contained union),
- a type that is a (possibly cv-qualified) base class type of the dynamic type of the object,
- a
char,unsigned char, orstd::bytetype.
However, the draft at eel.is/c++draft/ lists only 3 bullets (I highlighted the common ones):
If a program attempts to access the stored value of an object through a glvalue whose type is not similar ([conv.qual]) to one of the following types the behavior is undefined:
- the dynamic type of the object,
- a type that is the signed or unsigned type corresponding to the dynamic type of the object,
- a
char,unsigned char, orstd::bytetype.
P1359R0 explains the change:
The aliasing rules of [basic.lval] were adapted from C with additions for C++. However, a number of the points either do not apply or are subsumed by other points. For example, the provision for aggregate and union types is needed in C for struct assignment, which in C++ is done via constructors and assignment operators in C++, not by accessing the complete object. ... It has been suggested that the aliasing rules should be extended to permit an object of an enumeration with a fixed underlying type to alias an object with that underlying type.
Could you please explain in layman's terms the practical consequences of this wording change? As far as I understand, enum class E : T { ... }; is suggested to allow to alias T. Is this correct? Will anything else besides this become defined/undefined?
回答1:
There are no practical consequences.
This is a housekeeping clean-up to remove redundant/unused rules inherited from C (or older C++ standards). It doesn't quite meet the criteria of "editorial" because it's not just tinkering with grammar/spelling/formatting, but it's not a semantics change either.
The enum-related change you mention didn't happen; it's just a suggestion, mentioned in an "additional note" within the issue description. We could see this happen in future. Personally, I think that would be a good idea.
来源：https://stackoverflow.com/questions/59603620/p1359r0-basic-lval-wording-change-and-aliasing-rules