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