New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[basic.types] Clarify that 'value representation' does not depend on … #2246
Conversation
source/basic.tex
Outdated
of an object is the set of bits that hold | ||
the value of type \tcode{T}. | ||
of a type is the set of bits that hold | ||
the value in an object of that type. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't like that we're losing the parallel between "object representation" and "value representation" here (the former is a property of an object, the latter a property of a type). Maybe we could retain that and keep this approach by adding something like
The value representation of an object X of type
T
is the set of bits within the object representation of X corresponding to the value representation ofT
.
But I think that's still not quite capturing an important property: that the set of bits is the same for each object of the type. Perhaps we could relate the value representation of a type back to the sequence of N unsigned char
objects somehow ("which bits in which of the N unsigned char
objects taken up by an object of the type participate in representing the value of an object of the type" or something like that?).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jensmaurer: Ping
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok, I've changed the wording along the suggestion. It seems safe to say that the bits of the value representation are always a subset of the bits comprising the object representation; it's unclear why that was previously highlighted for trivially-copyable types only.
@zygoloid, your love is next.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe the idea of the prior wording is that for non-trivially-copyable (and non-standard-layout) types, the implementation is allowed to allocate some storage "elsewhere" to hold members of the type -- there is no guarantee that the members of such a type are actually stored within it.
One way this can happen (theoretically) is that a virtual base class is dynamically allocated separately from the object, and the object merely holds pointers to it; another way is that some of the storage for an object can be held separately in a GC heap. However, in practice, I'm not sure either approach is actually conforming because of the [basic.life] rule permitting an object to be discarded by merely reusing its storage.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, good point. Since waiting for CWG on this matter is probably in vain for the next meeting or so, I've restored the "value representation might be partially outside object representation" meaning. This is now a pure "value representation" wording fix-up with no change in meaning, so should be fine to be applied editorially.
e3dbfe2
to
1a21a65
Compare
+CWG for the "are non-trivially-copyable objects necessarily stored entirely within their object representation?" question. |
Removed CWG, since the question by @zygoloid is no longer asked in this pull request. |
…the value.
Fixes #2105.