Date: Fri, 17 Jan 2014 23:16:19 +0800
On Jan 17, 2014, at 9:53 PM, Gabriel Dos Reis <gdr_at_[hidden]> wrote:
> As for an object type with “trivial initialization”, I suspect that the general confusion comes from the fact for some reasons the standards text assumed that it could just “optimize” that case without much confusion. But evidence appear to suggest otherwise. Complexity has grown, with increased likelihood of inconsistency. What is the meaning of T{ } when T is a POD struct? Do you think there is no lifetime there?
My impression (for what it’s worth) is that a lifetime is required to exist in a retroactive sense around every subobject access. But the lifetime of a POD object does nothing but grant the possibility of accessing a subobject, which in turn has no special properties or invariants by virtue of the complete object.
So it’s not to say there’s no lifetime there, but POD lifetime is a meaningless concept because you can always just pull one out of thin air. (T{} is value-initialized, and assigning those zeroes does imply subobject accesses to be sure.)
What evidence otherwise? It sounds like Richard is trying to push the envelope, but one would have to review existing verification/test tools to see if anyone has really tried to do anything with POD lifetimes. In a very real sense, POD objects are handed to any C++ program by the OS libraries in a fashion opaque to (outside the scope of) most verification tools. Programs need original input data to come out of thin air, and POD provides a way to structure such data while preserving its bytestream-like purity.
> As for an object type with “trivial initialization”, I suspect that the general confusion comes from the fact for some reasons the standards text assumed that it could just “optimize” that case without much confusion. But evidence appear to suggest otherwise. Complexity has grown, with increased likelihood of inconsistency. What is the meaning of T{ } when T is a POD struct? Do you think there is no lifetime there?
My impression (for what it’s worth) is that a lifetime is required to exist in a retroactive sense around every subobject access. But the lifetime of a POD object does nothing but grant the possibility of accessing a subobject, which in turn has no special properties or invariants by virtue of the complete object.
So it’s not to say there’s no lifetime there, but POD lifetime is a meaningless concept because you can always just pull one out of thin air. (T{} is value-initialized, and assigning those zeroes does imply subobject accesses to be sure.)
What evidence otherwise? It sounds like Richard is trying to push the envelope, but one would have to review existing verification/test tools to see if anyone has really tried to do anything with POD lifetimes. In a very real sense, POD objects are handed to any C++ program by the OS libraries in a fashion opaque to (outside the scope of) most verification tools. Programs need original input data to come out of thin air, and POD provides a way to structure such data while preserving its bytestream-like purity.
Received on 2014-01-17 16:16:33