Section: 17.2 [support.types] Status: C++17 Submitter: Richard Smith Opened: 2016-05-10 Last modified: 2017-07-30 20:15:43 UTC
View all other issues in [support.types].
View all issues with C++17 status.
Per 17.2 [support.types]/4:
"The macro offsetof(type, member-designator) accepts a restricted set of type arguments in this International Standard. If type is not a standard-layout class (Clause 9), the results are undefined. [...]"
Implementations in practice interpret this as meaning that the program is ill-formed for classes that are not standard-layout, but several implementations allow additional types as an extension (rejected in their "strictly conforming" modes).It would seem superior to specify that implementation-defined extensions are permitted, and that the implementation must give a correct answer for any type that it chooses to accept.
[2016-05 Issues Telecon]
People were worried about the requirement to report errors implied by 'conditionally supported'.
The concern about errors appears to be less severe that we thought. Moving to Ready.
Friday: status to Immediate
This wording is relative to N4582.
Change in 17.2 [support.types]/4:
-4- The macro offsetof(type, member-designator) accepts a restricted set of type arguments in this International Standard.
If type is nota standard-layout class (Clause 9) , the results are undefined.193 The expression offsetof(type, member-designator) is never type-dependent (184.108.40.206) and it is value-dependent (220.127.116.11) if and only if type is dependent. The result of applying the offsetof macro to a static data member or a function member is undefined. No operation invoked by the offsetof macro shall throw an exception and noexcept(offsetof(type, member-designator)) shall be true.