Boost logo

Boost :

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
> > 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
> 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

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

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