[boost] Re: Re: ptr<>

From: Philippe A. Bouchard (philippeb_at_[hidden])
Date: 2002-08-22 23:47:57

"Larry Evans" <jcampbell3_at_[hidden]> wrote:
> Philippe A. Bouchard wrote:
>
> >s_offset could use something similar to map_offset also, but I would
> >personally prefer a fragmented vector or simply some limited (min, max)
> >vector because direct access is faster.  The bound vector would
contribute
> >for mathematics & their huge matrix simplifications at the same time.
Can
> >you alter map_offset for bound_vector (or bvector) Larry?
> >
> >
> Phillippe, I hadn't really thought about it much, except that the vector
> is best
> for speed reasons.  The only disadvantage of the vector is it might have
> a lot
> uf undefined entries.

Well it's not that bad because chances are that typeids will be grouped
together.  Ex.: range [10-30] libstdc++, range [50-150] libboost-dev, range
[180-230] personnal usages, ...

> This memory disadvantage is most likely very
> small compared
> to the memory used by the actual data.  The main disadvantage, with more
> documentation, is questions in the minds of people trying to understand
the
> implementation.
>
> I've another suggestion.  Since only the complex heirarchy needs the
> typeid, why
> not just use something else for the other 2 heirarchies.  That way,
> people wouldn't
> wonder what the use of typeid is to the other types of heirarchy.  Of
> course, that
> means a different placement new, and maybe that's to much bother.  I
> could understand
> either way.

IMO it is less error-prone because the user uses the same placement operator
new () each time.  On the other hand, class ptr<> could always be fragmented
into 3 distinct classes: ptr_simple<>, ptr_complex<> and ptr_ambiguous<>.
No need for hierarchy_traits<> anymore.  It's more a pro/cons situation and
I'm not sure yet either.

Philippe A. Bouchard