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
advantage...

Thanks,
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$1_at_main.gmane.org...
> >
> >>[...]
> >>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
about
> 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
method.
> See http://www.hpl.hp.com/personal/Hans_Boehm/gc/ for details.
>
>
> _______________________________________________
> Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk