Quote:Original post by jpetrie
Well, here's the thing, lexchou.
... ...
*Thanks for your reply, hehe
the first reply of this post is my solution to the original question o(>_<)o>>First, you did not provide a solution to the original question. A pointer-to-member-of-A does not carry with it any information about which specific A it was constructed from, because, again,
it was not constructed from a specific A, which means it
cannot be used to recover a pointer to A from a regular pointer or a pointer-to-member (which is what the original poster wanted). Your own example illustrates this quite clearly, since you a) construct a pointer-to-member-of-A without a specific instance of A, and b) use that pointer-to-member-of-A on a specific instance of A, failing to solve the original poster's problem.
*A pointer-to-member-of-A indeed does not carry with any information about the struct A's instance, but, it is the meta data just like in Delphi's RTTI, .net's reflection, that can be used with a struct's instance to access the concrete member, although it is a naughty way.
>>Second, your follow-up code
*may be the code I wrote is wrong, but this trick used in many places, the first place I saw it is in Matthew Wilson's <Imperfect C++> #- -
>>is not reliable; in fact, it is guaranteed to produce undefined behavior. Just because it might work in practice doesn't mean it is correct. Even it were correct, it
still does not answer the original poster's question since it provides you with (what you hope to be) a byte offset from the beginning of an object of type A to a given member of A; but this is not the data that the original poster has.
*hehe, i thought if i have an offset of a member in a struct, i can access the member in any instance of that kind of struct. the post's title is pointer_from_member, and the pointer_from_member=pointer_of_struct+offset_to_member, that's what I though.
>>First and foremost, you've relied upon the value-representation (i.e., the bits) of a pointer being well-defined as byte addresses. They are not. The standard explictly states that the value representation is up to the implementation, and thus unreliable.
*I relied on a POD type, that's because the poster used a POD type #-_-
>> Second, you assume that the null pointer is 0. It isn't, neccessarily. A constant integral expression that evaluates to zero will be converted to the null pointer value, but that value is implementation defined and need not neccessarily have an all-zero bit pattern. It could easily, in some places, be a segment:offset style form with the bitpattern (0x77770000), perhaps, in which case your offset will be quite amusing. And useless as an offset.
*haha, I'm wrong #-_-, i've never been programming in that sorts of platform, just heard of it before
>>Finally, you deference null. The standard draft I have here is wishy-washy on this at the moment; a number of places indicate that dereferencing null is undefined, but the definition of unary operator * does
not, as you might expect. Supposedly this was cleared up for the 2003 draft, or will be cleared up for the 0x draft -- the resolution I'm looking at was dated 2000, and I don't have a newer copy of the standard handy so I can't be sure.. However, the proposed clarification is that the dereference is legal... but the subsequent
use of the value is undefined. And you use the value. So either way, you've done something naughty.
*even though I deferenced a null pointer, but that just a syntax form, actually I didn't access the memory arround the null pointer, just let the compiler translate that to an offset.