Date: Sat, 18 Jan 2014 08:20:53 +0800
On Jan 18, 2014, at 7:49 AM, Gabriel Dos Reis <gdr_at_[hidden]> wrote:
> No, we would have exception for non-static data member access for unconstructed objects – this would be conceptually the same form of exception we grant in constructors for vcalls or typeids and even certain member access.
But how do you know what object is unconstructed? 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.”
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 know about rules in C, but as far as I know in C++, you can just arbitrarily decide to reinterpret bytes of memory as one POD or another, as long as they are “congruent,” by mangling the concepts of lifetime and allocation.
> No, we would have exception for non-static data member access for unconstructed objects – this would be conceptually the same form of exception we grant in constructors for vcalls or typeids and even certain member access.
But how do you know what object is unconstructed? 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.”
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 know about rules in C, but as far as I know in C++, you can just arbitrarily decide to reinterpret bytes of memory as one POD or another, as long as they are “congruent,” by mangling the concepts of lifetime and allocation.
Received on 2014-01-18 01:23:32