[boost] Re: Proven ptr<>

From: David B. Held (dheld_at_[hidden])
Date: 2002-08-12 14:40:22

"David Abrahams" <dave_at_[hidden]> wrote in message
news:042201c24229$3a13be60$6501a8c0_at_boostconsulting.com...
> [...]
> I haven't been paying enough attention to your implementation details
> to know whether a container is appropriate or neccessary, nor what
> s_rectify is.

For those without the inclination to wade through the code, here is my
understanding of how Philipe's ptr<> works:

class Base { };
class Derived : public Base { };

ptr<Derived> pDerived;
// ptr<Derived>::s_rectify[] = {0}

ptr<Base> pBase(pDerived);
// ptr<Base>::s_rectify[] = {0, 2}

The numbers in s_rectify are for illustration only.  The idea is that when
you access a polymorphic object, it computes the offset to return by
adding s_rectify to an internal pointer to the object, like so:

  element_type * get() const
  {
   return m_ptr + s_rectify[get_type_id()];
  }

However, this code is misleading, because s_rectify is a vector of
offsets, which means we need to consider this:

template <typename T>
 inline T * operator + (T * p1, offset p2)
 {
  return reinterpret_cast<T *>(reinterpret_cast<char *>(p1) +
static_cast<int>(p2));
 }

So to see what get() is really doing, here is the expanded equivalent:

element_type * get() const
{
    return reinterpret_cast<T *>(
        reinterpret_cast<char *>(m_ptr) +
        static_cast<int>(s_rectify[get_type_id()])
    );
}

That looks to me like adding an integer offset to a char* to get at the
internals of a non-POD object.

In order to compute the offsets, he does this:

    s_rectify[...] = int(static_cast<T *>((U *) 1) - offset(1));

Whether all this is conforming code I'll leave up to the language lawyers.

Dave