Boost logo

Boost :

From: williamkempf_at_[hidden]
Date: 2001-07-02 12:33:06

--- In boost_at_y..., "Peter Dimov" <pdimov_at_m...> wrote:
> From: <williamkempf_at_h...>
> > > You don't look convinced that a handle/body based design is
> > to use,
> > > though.
> >
> > I'm not. The only example given by either of us that indicates
> > ease of use is the example you just gave with a vector.
> If you expand the examples that had a thread_manager or a
thread_group in
> them, giving the full implementation, you'll see that they, too,
> the same point.

No, they don't, actually. Any difficulties in use (minimal) are
eliminated by the other concepts.

> > However, we
> > deal with this all the time in C++ using a smart pointer, and the
> > ease of use with a smart pointer is nearly identical even if the
> > overhead becomes a wash again. In fact, the thread ref concept is
> > just a variation on a smart pointer!
> Of course it is! Call it whatever you like, a smart pointer, a
handle, or a
> thread reference.
> So, your unspoken question is probably "why provide a thread::ref
when we
> already have shared_ptr?"

No, that's not really the issue. Ref-counting is the exception, not
the rule, to the need for lifetime management. Explicit ownership is
the norm, which is also much more efficient.
> Here's an example of creating a thread:
> shared_ptr<thread> p(new thread(f));
> This requires an explicit 'new', which several people have objected
to. An
> easy way to eliminate the 'new' is:
> shared_ptr<thread> p = thread::create(f);
> This is better, but a custom thread-safe reference counted smart
> may, under some conditions, outperform shared_ptr. (Plus, its
> isn't exactly what you want.) So we get to:
> thread::ref p = thread::create(f);
> Now the only question left is whether we need the
underlying 'thread' object
> or not. I've not been terribly successful in convincing people that
it's, in
> fact, not needed - and sometimes harmful - so it will probably
survive, much
> to my dissatisfaction. Such is life.

I'm not convinced that we need anything but the underlying type.
Again, it's a rare idiom that needs ref-counting for lifetime

Bill Kempf

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