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

From: Larry Evans (jcampbell3_at_[hidden])
Date: 2002-08-06 08:08:42

Philippe A. Bouchard wrote:

>(Sorry for the late reply, I was away).
>
[...]

>
>The pointer (pointing to the start of the allocated block) is adjusted when
>dereferenced depending on its relative position in the class hierarchy.
>This offset is calculated when different combinaisons of pointers and
>pointees are first encountered.
>
>[...]
>
[...]

>
>Sorry about it...  It was not well explained:
>- sizeof(allocated block of new (rc()) T) = sizeof(T) + sizeof(int) * 2;
>
With regard to the "sizeof(int)*2" term, is one int for the reference 
count and
the other for the offset from the start-of-object?

>>>- speedof(* ptr<T>) = speedof(* T) + C.
>>>
>
>The pointer is adjusted just before it is dereferenced.  C is really just of
>timeof(operator []) + timeof(operator +) in time and is negligible when
>
[...]

>
>I'm cleaning up the code according to the manner you might be interested...
>
Most definitely.
 
On a related matter, do you think the following code:

    typedef gc_method_subj_btm<gc_method_type,element_type> gen_type;

    ptr(gen_type * a_gen = 0) : m_gen(a_gen), m_ptr(a_gen->get_subj())

would be less error-prone?  It would be easy for a user who's careless
or in a hurry to just substitute "new T" as an argument instead of the
required "new (rc()) T ".  The above prevents this.  The user must
got out of his way to generate a "new gc_method_subj_btm<...>".  It's
a hassle, but it prevents hard to find errors later.  It could be made even
more fool-prove by providing a mk_heap_ptr class which is like
auto_ptr except that it ALWAYS creates a new instance and deletes
it if it hasn't been "acquired" by a ptr via a ptr CTOR call with 
mk_heap_ptr<T>
argument.  The disadvantage is that a specialization is needed for 
anything other
than a default construction of the T; however, the extra safety would be 
worth it
to me and maybe others.