Boost logo

Boost :

From: Beman Dawes (bdawes_at_[hidden])
Date: 2001-06-22 08:05:21

Ross Smith 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 the
>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.
>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?
>Similarly, why have a special create() function instead of an ordinary
>constructor, when constructors work perfectly well for every other
>non-copyable entity (iostreams etc.)?

Thanks, Ross! You did a better job articulating these concerns than I have
been doing.

>I really don't understand what problem you're seeing with this approach.

I don't either, I'm afraid. We really need a coherent rationale - we are
going to have to defend the design over and over again and need to be able
to get across why the usual C++ idiom for noncopyable objects doesn't apply
to threads.

To be blunt, it is still sounding to me like the main argument is simply
that traditional threads programming always trafficed in handles, and so
that approach is well understood by expert threads programmers. But you
could have said the same thing about FILE* at one time. I'm awfully glad
we moved on from there.

I expect there is more rationale than that for trafficing in thread
handles. But I'm just not understanding what it is, and need my mind
expanded. I'm trying to help Bill with documentation, and it is hard to do
if I can't understand the rationale for a handle based approach.


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