"David Abrahams" <dave@[...].com>  wrote in message
news:042201c24229$3a13be60$6501a8c0@[...]..
>  [...]
>  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





_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost