Boost logo

Boost :

From: David Abrahams (david.abrahams_at_[hidden])
Date: 2001-09-02 08:46:01

----- Original Message -----
From: "Greg Colvin" <gcolvin_at_[hidden]>

> > In this particular case, I wanted an embedded reference count, a
> > allocator, and an embedded size which could be passed to the allocator
> > destruction.
> Wouldn't Peter's design handle the last two items?

Sorry, I'm not aware of a design by Peter... but in fact, I don't want to
store the size directly. Instead, I want to store the number of elements
(it's an array that I'm managing).

> > Admittedly, the chances that a shared_ptr will be reset to point at the
> > object are slim, but if it /does/ happen, there's a good chance that the
> > same code could reset it to point at some other object which is already
> > managed (to see this, ask yourself, "why would a programmer ever
> > intentionally reset() a smart pointer to the same value?" I can think
> > reasons, but it's a bit of a stretch). This is is the only chance we get
> > catch a very common source of bugs. Currently, we have a precondition
> > this one for reset (is it documented?): "the argument must not point to
> > object whose lifetime is managed by another smart pointer...unless it's
> > same one that you are calling reset on". I propose to take out the
> > for this one case so that we stand a chance of detecting real bugs.

BTW, I also think that most of these bugs come from shared_ptr construction,
not reset. And there's nothing we can do in the construction case. :(

> If you have a function like
> shared_ptr<stuff> create_stuff(T arg) {
> return shared_ptr<stuff> (new stuff(arg));
> }
> then a function like
> void recreate_stuff(stuff_ptr& p, T arg) {
> p.reset(new stuff(arg));
> }
> might be more efficient than
> my_stuff_ptr = create_stuff(arg);

Sure, I guess, but by how much? recreate is still doing a dynamic allocation
and a construction.


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