From: Peter Dimov (pdimov_at_[hidden])
Date: 2001-07-02 10:59:49
> > You don't look convinced that a handle/body based design is easier
> to use,
> > though.
> I'm not. The only example given by either of us that indicates more
> 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, demonstrate
the same point.
> 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
So, your unspoken question is probably "why provide a thread::ref when we
already have shared_ptr?"
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 pointer
may, under some conditions, outperform shared_ptr. (Plus, its operator==
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.
-- Peter Dimov Multi Media Ltd.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk