Pointers-to-members

[Mark Mitchell]

>>>>> "Jim" == Jim Dehnert <dehnert at baalbek.engr.sgi.com> writes:

    Jim> I've added new issues A-26/27 for the representation of NULL
    Jim> pointers to members.  But I have a couple of questions:

    Jim> -- For a pointer to member function, if the function is
    Jim> non-virtual, it doesn't seem that one ever needs to worry
    Jim> about the adjustments.  If it's the same target function
    Jim> address, the only significance of the adjustment is how much
    Jim> you modify this before calling it, which is a property of the
    Jim> containing class rather than of the target.

You still need to know whether or not the adjustment is guaranteed or
not -- if it is, then you have to make sure to keep it zero, and if it
isn't then you have to generate more complex code when doing
comparisions.

    Jim> -- But if the function is virtual, the "pointer" is an offset
    Jim> into the vtable, and if you really want to identify whether
    Jim> the ultimate function is the same it gets really messy,
    Jim> especially if you need to pass through "thunks" first.  Is
    Jim> this the semantics, or is it much simpler for some reason?

Ooh, ugh.  But in [expr.eq] we have:

  Otherwise  if either is a pointer to a virtual member func-
  tion, the result is unspecified.

so, we can do what we wish.

    Jim> -- For a pointer to member data, Jason had me convinced that
    Jim> the displacement would never go negative because the bases
    Jim> are allocated before additional data members in the derived
    Jim> class, until I thought about virtual bases, where that's no
    Jim> longer true.  Is there a C++ restriction that makes this not
    Jim> a problem, or...?

I think I submitted a "proof" of the non-negativity of
pointers-to-members in all cases.  I believe that you can't cast a
D::* to a B::* if B is a virtual base.

--
Mark Mitchell                   mark at codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com