Re: [boost] Re: Proven ptr<>

From: David Abrahams (dave_at_[hidden])
Date: 2002-08-12 00:53:02

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_at_[hidden] * http://www.boost-consulting.com

----- Original Message -----
From: "Greg Colvin" <Gregory.Colvin_at_[hidden]>
To: <boost_at_[hidden]>
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
>