Boost logo

Boost :

From: Philippe A. Bouchard (philippeb_at_[hidden])
Date: 2002-08-07 20:03:26

> >I've cleaned up the polymorphic ptr<> class:
> >
> Thanks. I've been waiting for the other shoe to drop.
> I've been looking at your source, and I really don't understand
> what it is trying to do, let alone how it does it. Please explain.

struct X { virtual ~X() {} };
struct Y { virtual ~Y() {} };
struct Z { virtual ~Z() {} };
struct P : X, Y { virtual ~P() {} };
struct Q : X, Y, Z { virtual ~Q() {} };

ptr<P> = new X;
ptr<P> = new Y;
ptr<P> = new P;

ptr<Q> = new X;
ptr<Q> = new Z;

Will generate those static members:
ptr<P>::s_id = 0; // unique id
ptr<X>::s_id = 1;
ptr<Y>::s_id = 2;
ptr<Q>::s_id = 3;
ptr<Z>::s_id = 4;

ptr<P>::s_rectify = {0, 0, 4}; // Lookup table of different static_cast<P
*>() offsets
ptr<Q>::s_rectify = {u, 0, u, u, 8};

The information will be specific to each .cpp source file since static
members are declared in the header. This will help to reduce the size of
s_rectify since it is directly proportional to the number of static_cast<>
combinaisons the .cpp file will need (for
__type_traits<T>::has_trivial_constructor = __false_type).

> What I think you are trying to do is allocate the counter along with
> the object and then recover the counter given only a pointer to the
> object. This lets sizeof(ptr<T>)==sizeof(T*) which is a very nice
> property. To accomplish this you are willing to insist that the T
> object be allocated with a placement new syntax, which is fine if it
> works. Beyond that I am lost in your has_trivial_destructor and
> reinterpret_cast games. As far as I know there is no portable way
> to do what you are trying to do, but I'd be glad to be proved wrong.

has_trivial_destructor is a temporary trait (not many choices are given in
the standards first of all) but can easily use another one. The advantage
of has_trivial_destructor is that it is sometimes supported by compilers.
You won't need to explicitly generate those __type_traits partial
instanciations. I would like better suggestions eventually.

reinterpret_cast<> in constructors is used to copy the exact location of the
pointer. Otherwise it will be implicitly static_cast<>ed. Other
reinterpret_cast<>s are used to access counters and ids.

> There are nonportable ways to do it that you can find in the memory
> management literature if that is what you are trying to do.

Nonportable ways of doing what exactly?

> >- Lookup tables could be optimized more but are already reasonnable in
> >ressources.
> What lookup tables?

vector ptr<T>::s_rectify.

> What resources?

Memory and CPU cycles.

Philippe A. Bouchard

Boost list run by bdawes at, gregod at, cpdaniel at, john at