pointer-to-member comparison

[aschepler]

Consider this compilation unit:

struct Base {};
struct A : public Base { int x; };
struct B : public Base { int y; };
int Base::*const px = static_cast<int Base::*>(&A::x);
int Base::*const py = static_cast<int Base::*>(&B::y);

bool f() {
return px == py;
}

First, is the program ill-formed? Or is the behavior undefined?
5.10p2 says px == py "if and only if they would refer to the same
member of the same most derived object (1.8) or the same subobject if
they were dereferenced with a hypothetical object of the associated
class type." I assume the "associated class type" here is Base. But
5.2.9p9 and 5.5p4 make it clear that dereferencing an object with
dynamic type Base using px or py gives undefined behavior.

If the above is ill-formed or undefined, does it follow that the
expression (px == px) has the same problem?

Not too surprisingly, my compiler has the above f() return true. If
this happens, it seems reasonable to assume that the following also
always returns true, although the a.*py is technically at best
undefined:
bool g( A& a ) {
return &(a.*py) == &a.x;
}

Realistically, it seems like I can count on the "logic" that f()
implies g(), even though the Standard doesn't technically guarantee
this. But if any of this is ill-formed, I want to avoid it.

 

[Andrey Tarasevich]

Consider this compilation unit:

struct Base {};
struct A : public Base { int x; };
struct B : public Base { int y; };
int Base::*const px = static_cast<int Base::*>(&A::x);
int Base::*const py = static_cast<int Base::*>(&B::y);

bool f() {
return px == py;
}

First, is the program ill-formed?

No. Every statement here is perfectly well-formed.

Or is the behavior undefined?

I'd expect so. Although the language specification doesn't seem to
address this situation.

5.10p2 says px == py "if and only if they would refer to the same
member of the same most derived object (1.8) or the same subobject if
they were dereferenced with a hypothetical object of the associated
class type." I assume the "associated class type" here is Base.

I'd also assume the same thing.

But
5.2.9p9 and 5.5p4 make it clear that dereferencing an object with
dynamic type Base using px or py gives undefined behavior.
Exactly.

If the above is ill-formed or undefined, does it follow that the
expression (px == px) has the same problem?

Hm... Good question. Formally speaking, it appears to be so.

 

[James Kanze]

Consider this compilation unit:

struct Base {};
struct A : public Base { int x; };
struct B : public Base { int y; };
int Base::*const px = static_cast<int Base::*>(&A::x);
int Base::*const py = static_cast<int Base::*>(&B::y);

bool f() {
return px == py;
}

First, is the program ill-formed? Or is the behavior undefined?

5.10p2 says px == py "if and only if they would refer to the
same member of the same most derived object (1.8) or the same
subobject if they were dereferenced with a hypothetical object
of the associated class type." I assume the "associated class
type" here is Base. But 5.2.9p9 and 5.5p4 make it clear that
dereferencing an object with dynamic type Base using px or py
gives undefined behavior.

If the above is ill-formed or undefined, does it follow that
the expression (px == px) has the same problem?

I don't think that the standard is really clear about this. All
of the statements until the == are well formed and fully
defined. The return statement with the == is also well formed,
but I'm not sure what the results are supposed to be. It's not
clear here what the "associated class type" is; if you read this
to mean that your px == py is semantically equivalent to
&someBObject.x == &someBObject.y, then you have a real problem,
because of course, that expression won't even compile; if you
replace the "someBObject."s with "ptrToSomeBObject->", then your
code would have undefined behavior. Which, I suspect, is
probably the intent (if one can speak of "intent" about a case
which was apparently not considered); any time the standard
doesn't define a specific behavior, the behavior is undefined.
(In this case, it would seem reasonable to have the results
unspecified, rather than the behavior undefined, but in
practice, I doubt that changes anything for real programs.)

Not too surprisingly, my compiler has the above f() return
true. If this happens, it seems reasonable to assume that the
following also always returns true, although the a.*py is
technically at best undefined:
bool g( A& a ) {
return &(a.*py) == &a.x;
}

If the comparison is undefined behavior, then you can't count on
anything. Until proof of the contrary, I think that this is
what you have to assume.

Realistically, it seems like I can count on the "logic" that
f() implies g(), even though the Standard doesn't technically
guarantee this.

I don't think so. It's quite possible for a compiler to include
type information in a pointer to member, which would invalidate
your assumptions.

But if any of this is ill-formed, I want to avoid it.

Not ill-formed, but undefined behavior is probably something you
should avoid as well.