I'm not sure if this ptr<>  type under discussion works this way, but in
general you can't conformingly use char* arithmetic with offsets to find
the sub-parts of non-POD types. I had a *long* discussion thread with John
Spicer of EDG about this, since I had to solve the same sort of problem to
handle inheritance in Boost.Python v2. Eventually, I decided I was willing
to use that technique only as an optimization, in case I ran into a
platform where it wouldn't work.

FWIW-ly y'rs,
Dave

-----------------------------------------------------------
           David Abrahams * Boost Consulting
dave@[...].com * http://www.boost-consulting.com


----- Original Message -----
From: "Greg Colvin" <Gregory.Colvin@[...].com> 
To: <boost@[...].org> 
Sent: Sunday, August 11, 2002 10:49 PM
Subject: Re: [boost] Re: Proven ptr<> 


>  At 02:30 PM 08/11/2002, Philippe A. Bouchard wrote:
>  >> As for the implementation, I think there are better approaches that
>  >> would cause no penalty for get().  The usual trick is to use size-
>  >> segregated storage pools set up so that one can get from an interior
>  >> pointer to an object header very quickly.  The Boost pool
implementation
>  >> can probably be tweaked for this purpose.  Then a mumble_ptr<T> can
just
>  >> store a proper T*, so get() has no overhead, and the arithmetic to
>  >> access the count is paid for only when needed.
>  >
>  >Uhh...  pool is an accelerated memory allocator, but still is a memory
>  >allocator.  If we would use the standard malloc(), reconstruction of
>  >containers would be like allocating a separate reference count.  Also
get()
>  >is not that slow: 1 more second for 1000 sorts of a 10000 element
container.
> 
>  I'm not sure of the tradeoffs, but you have to allocate a
>  reference count anyway, no?  And you are paying an extra
>  cost in space of about N*(N/2) offsets for a system with
>  N ptr<> types, yes?
> 
> 
> 
>  _______________________________________________
>  Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
> 

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost