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

From: Philippe A. Bouchard (philippeb_at_[hidden])
Date: 2002-08-07 01:29:09

I've cleaned up the polymorphic ptr<> class:
http://groups.yahoo.com/group/boost/files/ptr/

- The syntax is similar to SGI's for temporary readability issues.
- Namespace 'fdi' is temporary also.
- I feel more secure with LGPL.  I don't know about you people?
- Lookup tables could be optimized more but are already reasonnable in
ressources.
- Template friend classes are not well supported under gcc 2.95.4; some
internal classes are simply public.
- You can trick ptr<> with has_trivial_destructor for single parent
hierarchies; it will optimize speed even if you have virtual destructors but
this __true_type hack won't be portable although some other trait could be
officially used instead.

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

the second int is used to identify the exact type (some sort of id).

[...]

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

'new (rc()) T' is error-prone but it can be included in a displaced static
operator new (size_t) or simply wrapped into a macro (worse case scenario
here).  The problem with gen_type is that it will be constructed using a
temporary which implies copy constructor dependence of the object pointed
to.

[...]

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

Specializing every widgets in the QT library would be a problem here but the
general concept of having two pointers like this is already faster than 2
separate allocations & deallocations: one for the object, another one for
the counter.

Philippe A. Bouchard