Quote:
We do know which member we have in mind.
So there should be no information lost in the process.
Well, the compiler knows (some kind of offsetting has got to be stored in the value of a pointer-to-member), but the compiler doesn't provide a standard way to get that offsetting out of there. Nor can you safely cast a pointer-to-member to a regular pointer. The language just plan doesn't support this "features" (and for good reason).
The "bit pattern" is just another word for the value. The value of a pointer is an address, but the format of that address is implementation defined. Memory isn't neccessarily linearly addressable (some machines address is differently), and C++ has to cope with that, so you can't, in turn, expect linearly-addressable-interpretations of a pointer to be valid. Additionally, the standard says that a constant integral expression evaluating to zero shall be converted to the null pointer value at compile time. This means that a, in "int a = 0;" can legally contain, in memory, at run-time, a non-zero value, if the target machine uses a non-zero value for the null pointer. It is possible and it does happen.
The FAQ you quoted is for C. C isn't C++. Are we talking about the same language, here? It doesn't change the validity of the "constant expression of zero is null" statement, but it does change other things.
Doing "math" on pointers that point to different arrays/objects isn't well defined. There's no object at the null pointer value. Thus, the math isn't well defined.
Quote:
The discussion clearly concludes that it is the standard itself that has been mis-worded on that matter. And that we shouldn't be paranoid about it.
It shows a mis-wording, true. But to me, that means one should be as conservative as possible about the issue.
As far as the intrusive list concept, since you're being intrusive, why don't you be just slightly more intrusive and hold a more complicated object in the host class that can be told the information about "which object holds me" so that it can be queried later? There's no reason to muck about with pointers like this.