[Boost-users] Re: Re: thread::thread() in Windows

From: Yuval Ronen (ronen_yuval_at_[hidden])
Date: 2004-12-09 04:14:18

> > > A default-constructed thread is documented as being non-joinable:
> > Ok, I can't join it. So what can I do with it?
> Not a whole heck of a lot aside from comparing it to other threads.

This brings me some thoughts.
The thread class is non-copyable (which is fine by me) and also it has an
operator==. I think these two things contradict each other. When defining an
equal operator, we are actually defining semantics for copying: copying an
object will result in a second object that will be equal, in terms of
operator==, to the first object. Defining an equal operator means that
objects can be equal, or in other works, they are a copies of the same
value!

To strengthen my point, I'll say that this not just theory, it's also
partially been done in practice, here in the thread class. The no-parameters
constructor is just that - it copies the current thread. The result of the
no-parameters constructor is a copy of the object representing the current
thread. Copies can be done!

IMHO, there are two possibilities: The first is to declare that threads are
in fact copyable and providing full support for that (copy constructor,
etc.). And again, copying them means creating a second object that is
'opeator==' equal to the first. The second possibility is to insist that
threads are non-copyable. That means that the no-parameters constructor and
the equal opeator have to go, because they contradict this concept. But do
we loose functionality if we erase those? If we agree that the only use for
them is the ablity to write some like like:

bool is_current_thread(const thread &t)
{
    return t == thread();
}

then it would be much better to have a member function
    bool thread::is_current() const;
that will do just that. It's much more accurate and expressive to use ' if
(some_thread.is_current())' then to use 'if (some_thread == thread())'.

I hope I was persuasive,
Yuval