31

The C++17 Standard says in [support.types.layout]:

Use of the offsetof macro 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?

Improve this question
3
  • 1
    IIRC offsetof is in the process of being revised for C++20, getting rid of the "conditionally-supported" part, adding the notion of stable-layout classes, and/or extending the current definition of standard-layout. I don't remember the specifics though, and can't remember where I read that :/ Commented Nov 28, 2017 at 0:04
  • @Morwenn - It it p0545r0 you had in mind? Commented Nov 29, 2017 at 14:17
  • @StoryTeller Yes, it looks like it :) Commented Nov 29, 2017 at 14:18

1 Answer 1

Reset to default
20

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 offsetof for 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."

Improve this answer
Sign up to request clarification or add additional context in comments.

9 Comments

UB or ill-formed? The difference is, admittedly, subtle.
@Yakk - I don't see anything in the definition of the macros semantics or standard layout types that calls it ill-formed (either with a required diagnostic or not). I think that leaves us with UB.
honestly conditionally supported is really no different than an implementation choosing to define undefined behavior... it's still not portable and is still dangerous.
Code that exhibits UB that would run can cause time-travelling nasal demons. UB exhibiting code that cannot run cannot cause time-travelling nasal demons. Ill-formed code (code that makes your program ill-formed) that cannot run (is unreachable) can cause time-travelling (dimension hopping?) nasal demons. The difference is real; claiming that it is merely UB because it doesn't say it is ill-formed seems overly optimistic. Ill-formed programs have no requirements placed on them by the standard. Programs whose abstract machine executes UB have no requirements placed on them.
[intro.compliance]/2.2: "If a program contains [...] 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."
|

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.