Re: [boost] Re: Re: Extensible polymorphic pointer for speed & memory

From: Greg Colvin (Gregory.Colvin_at_[hidden])
Date: 2002-08-08 13:49:54

At 07:03 PM 08/07/2002, Philippe A. Bouchard wrote:
>> >I've cleaned up the polymorphic ptr<> class:
>> >http://groups.yahoo.com/group/boost/files/ptr/
>>
>> 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.
>
>Given:
>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).

Say what?

You can define only one instance of a static member per class.

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

Of managing memory so that given a pointer to the interior
of an object you can recover a header associated with that
object.  For example, http://www.hpl.hp.com/personal/Hans_Boehm/gc/

>> >- 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
>
>
>
>
>
>_______________________________________________
>Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost