Date: 2001-06-22 09:16:04
--- In boost_at_y..., Ross Smith <ross.s_at_i...> wrote:
> Greg Colvin wrote:
> > If one has only the non-copyable thread object then one
> > is tempted to traffic in raw pointers to that object, with
> > either the usual risks of dangling pointers or else the
> > requirement to keep the thread object around forever.
> Why do you see this as a problem specific to threads? It's exactly
> same for iostreams, and for that matter for anything else that's
> non-copyable. Making objects non-copyable when the concept they
> represent isn't naturally copyable is generally considered a _good_
> thing by most C++ programmers.
It's a problem specificly for threads because it's very common to
have to pass around references to other objects to allow them to
manage the thread. In fact the two most common idioms are to either
create the thread and discard the reference (close the handle in
Win32 threads or call detach() for pthreads) allowing it to manage
itself, or to immediately pass the id/descriptor/handle/reference to
another object(s) for management.
> As for being "tempted to traffic in raw pointers", surely this is
> exactly the sort of problem std::auto_ptr and boost::shared_ptr were
> created to solve?
Only when the object is created on the heap.
> Similarly, why have a special create() function instead of an
> constructor, when constructors work perfectly well for every other
> non-copyable entity (iostreams etc.)?
I mostly chose this approach to make it impossible to derive a class
from thread (the constructor(s) are private). This choice isn't set
in stone yet, however.
> I really don't understand what problem you're seeing with this
I've outlined the two major problems. Greg caught one here when he
mentions the need to create the thread objects on the heap and manage
the raw pointers. The other is that an object that fully represents
the execution state instead of just referencing it should destroy
this state in it's destructor, and this practice is very dangerous.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk