Menu
The C++17 Standard says in [support.types.layout]:
Use of the
offsetofmacro with a type other than a standard-layout class is conditionally-supported.
And in [defns.cond.supp]:
conditionally-supported
program construct that an implementation is not required to support
I find this definition of offsetof not very precise.
Does it mean that I can safely attempt to use this with non standard-layout classes?
How is "conditionally-supported" different from implementation defined?
Is a compiler not supporting offsetof for a particular type of class required to produce a diagnostic?
394
The offsetof macro returns the offset in bytes of memberName from the beginning of the structure specified by structName as a value of type size_t. You can specify types with the struct keyword. Note. offsetof is not a function and cannot be described using a C prototype.
Defined in header <cstddef> #define offsetof(type, member) /*implementation-defined*/ The macro offsetof expands to an integral constant expression of type std::size_t, the value of which is the offset, in bytes, from the beginning of an object of specified type to its specified subobject, including padding if any.
It evaluates to the offset (in bytes) of a given member within a struct or union type, an expression of type size_t. The offsetof() macro takes two parameters, the first being a structure name, and the second being the name of a member within the structure.
Use offsetof() to find the offset from the start of z or from the start of x . #include <stddef. h> size_t offsetof(type, member); offsetof() returns the offset of the field member from the start of the structure type.
Does it mean that I can safely attempt to use this with non standard-layout classes?
If the implementation permits it. Being conditionally supported means this must be documented.
How is "conditionally-supported" different from implementation defined?
To quote the standard on this:
[defns.cond.supp] conditionally-supported - "program construct that an implementation is not required to support"
[defns.impl.defined] implementation-defined behavior - "behavior, for a well-formed program construct and correct data, that depends on the implementation and that each implementation documents"
The key difference is what choice the implementation has. Do it exactly as the standard says, or not at all. Vs. doing it in one of several ways without an option to refuse.
Is a compiler not supporting
offsetoffor a particular type of class required to produce a diagnostic?
If it's a conforming implementation, it will issue a diagnostic ([intro.compliance]/2.2 courtesy of @T.C.):
"If a program contains a violation of any diagnosable rule or an occurrence of a construct described in this document as “conditionally-supported” when the implementation does not support that construct, a conforming implementation shall issue at least one diagnostic message."
187
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
