Boost logo

Boost :

From: David Brownstein (David_at_[hidden])
Date: 2002-07-30 16:19:57

I think that BEFORE we debate the technical small-print of a "fast pointer"
proposal, we should first agree that there is some deficiency in the current
set of std and boost supplied smart pointers that desperately needs to be
addressed. Gennadiy asked exactly this in an earlier message, and it was
never answered (at least not to my satisfaction!). As I remember the answer
he got back eventually was (to paraphrase): "there is nothing that doesn't
work, nothing that the current smart pointers won't do, this proposal is
just more efficient...". Is effiecency alone enough to just yet another
smart pointer? I believe the answer is "no", but I'm willing to be
convinced... What I need is a simple, concise argument that details exactly
what "efficiency" benefits a new implementation can provide.

As an aside, IF there are demonstrable efficiency benefits, then perhaps the
current crop of boost smart pointers can be altered or re-implemented to

David Brownstein

----- Original Message -----
From: "Larry Evans" <jcampbell3_at_[hidden]>
To: <boost_at_[hidden]>
Sent: Tuesday, July 30, 2002 1:49 PM
Subject: Re: [boost] Re: Proposal: boost::pool fast pointer

> David B. Held wrote:
> >"Philippe A. Bouchard" <philippeb_at_[hidden]> wrote in message
> >news:ai6r2j$534$
> >
> >>[...]
> >>ptr<Derived> pD = new Derived;
> >>ptr<Derived, X> pX = new X;
> >>ptr<Derived, Y> pY = new Y;
> >>
> >>pX = pD; // Won't work
> >>pY = pD; // Won't work
> >>[...]
> >>
> >
> >Of course, this syntax is clumsier than existing pointers, and also less
> >powerful. For instance, you may have code that knows about X or Y,
> >but not about anything derived from X or Y. Your proposal requires
> >such code to know about all possible derivatives in order to work
> >properly, which is a fairly restrictive requirement.
> >
> >Dave
> >
> The Boehm collector is able to find the beginning of an object given a
> pointer
> to the interior of that object. Could Boehm's method be adapted here so
> that,
> when trying to find the reference count, the Boehm method could be used to
> find the beginning of the object where the refcount is located, as
> assured by, for
> example, a special gc allocator? WARNING: I haven't thought carefully
> this.
> OTOH, this would probably make the overhead of reference count update
> significantly
> slower, but I can't be really sure since I'm unfamiliar with Boehm's
> See for details.
> _______________________________________________
> Unsubscribe & other changes:

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