From: Philippe A. Bouchard (philippeb_at_[hidden])
Date: 2002-08-07 09:18:35
I've cleaned up the polymorphic ptr<> class:
- The syntax is similar to SGI's for temporary readability issues.
- Lookup tables could be optimized more but are already reasonnable in
- 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.
Follows up 'Extensible polymorphic pointer for speed & memory' discussion:
> 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).
> 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
> 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
Philippe A. Bouchard
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk