Date: 2001-07-02 10:16:35
--- In boost_at_y..., "Peter Dimov" <pdimov_at_m...> wrote:
> From: <williamkempf_at_h...>
> > --- In boost_at_y..., Ross Smith <ross.s_at_i...> wrote:
> > > Looking back at the path the design has been taking recently, I
> > suspect
> > > we've diverged too far. I can't understand the liking so many
> > > have for the "thread_ref" concept. Non-copyable objects, with
> > > pointers when necessary, are the standard C++ idiom for this
> > > thing; why treat threads differently? I'm afraid I Just Don't
> > It.
> It depends on what you are modeling, of course, but in such
> noncopyable objects are rarely a good decision.
> Look at the C-style file functions, for instance:
> FILE * fopen(...);
> but not
> void fopen(FILE * f, ...);
> The actual - noncopyable - 'FILE' still exists, but it's hidden.
> have to declare an instance of FILE, or know anything about it.
> they work with FILE* - an opaque handle that is freely copyable. Of
> plain FILE* requires explicit ownership tracking, but it's possible
> rewrite these functions in C++ replacing a FILE* with a
> (without touching anything else) and have everything working
exactly as it
> should, without any explicit fclose's.
In C it's not really possible to make something noncopyable. Beman
rightfully points out that the C++ concept for this same thing is the
iostream, which is noncopyable. So the assertion that such concepts
should be copyable isn't met by your example here.
> If you look at existing thread libraries, you'll see the same
> actual noncopyable thread 'object' is hidden deeply in the
> you get only a HANDLE, or a pthread_id, that is exactly a
> the safety.
Again, this is because existing thread libraries are C libraries,
where there's no such thing as a noncopyable type. When modeling in
C++ it would likely be better to stick with existing practice and
make the C++ concept noncopyable.
> In this case the implementation has no choice, actually, because the
> lifetime of the hidden 'thread object' is controlled by the OS, not
Actually, it's controlled by both (thus the existance of
pthread_detach and CloseHandle).
> > Why are Win32 handles ref-counted concepts, with DuplicateHandle?
> To make C programmers' lifes easier, I guess. :-)
> > _That_ is why people feel more natural with a ref-counted design.
> No, not exactly. The primary motivation behind a thread::ref -
> is not that it'll use reference counting under the hood (I don't
> whether it will, as soon as it implements the spec.) It's simply
> lightweight copyable objects are so much easier and less error
prone to work
> with, to say nothing about the STL.
An object such as a thread object has to either be noncopyable, be
ref-counted (loose terminology), or rely on explicit instructions to
release the thread state. The noncopyable design is the typical C++
design. The explicit release is the typical C design, but is error
prone and so not the design preferred by C++ programmers. The ref-
counted design isn't widely used and suffers from performance
> And, of course, not exposing the noncopyable thread prevents
> inheritance attempts. :-)
Not much of a benefit, IMHO.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk