Skip to content
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

Merged
merged 1 commit into from Oct 9, 2018

Conversation

jensmaurer
Copy link
Member

…the value.

Fixes #2105.

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.
Copy link
Member

@zygoloid zygoloid Jul 6, 2018

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 of T.

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?).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jensmaurer: Ping

Copy link
Member Author

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.

Copy link
Member

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.

Copy link
Member Author

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.

@zygoloid
Copy link
Member

zygoloid commented Oct 8, 2018

+CWG for the "are non-trivially-copyable objects necessarily stored entirely within their object representation?" question.

@zygoloid zygoloid added the cwg Issue must be reviewed by CWG. label Oct 8, 2018
@jensmaurer
Copy link
Member Author

Removed CWG, since the question by @zygoloid is no longer asked in this pull request.

@jensmaurer jensmaurer removed the cwg Issue must be reviewed by CWG. label Oct 9, 2018
@zygoloid zygoloid merged commit e8fee95 into cplusplus:master Oct 9, 2018
@jensmaurer jensmaurer deleted the b3 branch October 9, 2018 23:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants