[boost] Re: Extensible polymorphic pointer

From: Philippe A. Bouchard (philippeb_at_[hidden])
Date: 2002-08-07 17:18:57

[...]

> > It will still work, you just live with redundant lookup tables.  But
this
> > problem is the main one with template usages.
>
> What about having source file with the static data?  Also, can you explain
> how get_type_id() works?  It seems to me that it could return a very large
> value.  There also seems to be no discernable relationship between the
> size of the space allocated by reserve() and the possible values returned
> by get_type_id().

Up to now I've just tested ptr.h with pointer.cpp; only one source file.  I
think gcc is duplicating templates & static members everywhere but can be
prevented with #pragma interface macros.

> > It is more extensible for speed & memory of large containers because
> > the pointer is of sizeof(int), allocations & deallocations are not done
> twice
> > for each object pointed to, less overhead on memory maps
>
> I don't see how these make it "extensible".  Perhaps we don't agree on
> what the word means.  When I see "extensible", I think: "Can be made to
> have different functionality".  The features you mention look like a set
of
> fixed functionality.

I was seeing 'extensible' as: "better runtime ressources extrapolations".

> > and we all know the that the custom deleter can also be integrated
> > eventually.
>
> And the big question is: When it is, will we just end up with
shared_ptr<>?

We could end up with a partial specialization of shared_ptr<> but not
shared_ptr<> itself.

[...]

> > The table is needed because it maps offsets associated with type T
> > and all the object this type could point to.
>
> I understand the intent, but for a given T, why would there be multiple
> entries in the table, and show me an example with plausible values.

The number of entries is directly proportional to the different number of
children casts.  Ex.:

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:
ptr<P>::s_id = 0;
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};
ptr<Q>::s_rectify = {u, 0, u, u, 8};

[...]

> > len<>() is usefull to implicitly generate offsets, but I'll look at
> > ptrdiff_t.
>
> I understand the purpose of len<>, but why not just use sizeof()
> directly?  The comments appear to imply that your indirection is
> faster than a raw sizeof() call.

Let's not forget that (int *) 0 + sizeof(double) will be equal to 0x20 since
the addition multiplies sizeof(int) sizeof(double) times.  It is so much
easier with offsets.

Philippe A. Bouchard