Date: Sat, 18 Jan 2014 13:06:24 +0800
On Jan 18, 2014, at 12:13 PM, Gabriel Dos Reis <gdr_at_[hidden]> wrote:
> | But how do you know what object is unconstructed?
>
> I do not understand the question; could you clarify?
>
> | An unconstructed object
> | pops into existence when you perform an access, and that's enough to validate
> | my awful example. This is what I meant by "retroactive."
>
> I don't understand. We define what it means for a raw memory to be constructed as an object.
You proposed that an access causes the memory to be treated from that point as an unconstructed POD object, just as access in a constructor. But that rule is already loose enough to render the idea of a lifetime essentially without effect.
The only criterion for having an accessible but not-yet-constructed POD object is trying to use it (as an overlay to memory that doesn’t already contain a non-trivially destructible object). Whatever you try to use, you have. That’s just the worst interpretation of the status quo.
> | Inside a constructor, the type of *this is well-defined, and the exception is
> | granted over a limited scope. Outside a constructor, it's a free for all.
>
> I don't understand this. I am saying that if you get dynamically allocated storage of proper alignment and size, then the first write access is, by definition, construction of an object of type given by the lvalue used to perform the write.
And then you can arbitrarily say that any point in the code is a user-defined dynamic allocator which enables a new lifetime to begin by reusing the storage. The comments in my earlier example emphasized this.
Perhaps what we need is a way to stop lifetimes from ending by reuse. Then requiring delete-expressions would be useful.
> | I don't know about rules in C,
>
> the relevant rules have been extensively referenced in this thread. There were a couple of messages specifically dedicated to that last night.
I know that if you try to alias structures in C, layout differences can bite you, but I don’t see what prevents you from doing so as long as layouts are the same (which can be checked using member-wise offsetof). “Congruence” is there in the title of this thread.
I haven’t seen anything like “effective type” for C structs or C++ POD class types. Aliasing rules only apply at lvalue-to-rvalue conversion of fundamental types.
So given the earlier discussion, I still don’t know what rules in C prevent you from punning congruent classes.
> | But how do you know what object is unconstructed?
>
> I do not understand the question; could you clarify?
>
> | An unconstructed object
> | pops into existence when you perform an access, and that's enough to validate
> | my awful example. This is what I meant by "retroactive."
>
> I don't understand. We define what it means for a raw memory to be constructed as an object.
You proposed that an access causes the memory to be treated from that point as an unconstructed POD object, just as access in a constructor. But that rule is already loose enough to render the idea of a lifetime essentially without effect.
The only criterion for having an accessible but not-yet-constructed POD object is trying to use it (as an overlay to memory that doesn’t already contain a non-trivially destructible object). Whatever you try to use, you have. That’s just the worst interpretation of the status quo.
> | Inside a constructor, the type of *this is well-defined, and the exception is
> | granted over a limited scope. Outside a constructor, it's a free for all.
>
> I don't understand this. I am saying that if you get dynamically allocated storage of proper alignment and size, then the first write access is, by definition, construction of an object of type given by the lvalue used to perform the write.
And then you can arbitrarily say that any point in the code is a user-defined dynamic allocator which enables a new lifetime to begin by reusing the storage. The comments in my earlier example emphasized this.
Perhaps what we need is a way to stop lifetimes from ending by reuse. Then requiring delete-expressions would be useful.
> | I don't know about rules in C,
>
> the relevant rules have been extensively referenced in this thread. There were a couple of messages specifically dedicated to that last night.
I know that if you try to alias structures in C, layout differences can bite you, but I don’t see what prevents you from doing so as long as layouts are the same (which can be checked using member-wise offsetof). “Congruence” is there in the title of this thread.
I haven’t seen anything like “effective type” for C structs or C++ POD class types. Aliasing rules only apply at lvalue-to-rvalue conversion of fundamental types.
So given the earlier discussion, I still don’t know what rules in C prevent you from punning congruent classes.
Received on 2014-01-18 06:07:15