Boost logo

Boost :

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,

           David Abrahams * Boost Consulting
dave_at_[hidden] *

----- 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
> >> can probably be tweaked for this purpose. Then a mumble_ptr<T> can
> >> 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
> >is not that slow: 1 more second for 1000 sorts of a 10000 element
> 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:

Boost list run by bdawes at, gregod at, cpdaniel at, john at