Re: Boost.Threads - thread_desc concept

From: williamkempf_at_[hidden]
Date: 2001-07-02 09:10:25

--- In boost_at_y..., "Alexander Terekhov" <terekhov_at_d...> wrote:
> 
> > > could you please explain why "thread types can't be extended
> > > through inheritance" ?
> >
> > Because they're not objects.  A Win32 handle can't be inherited
> > from.  A pthread_t descriptor can't portably be inherited from (on
> > many platforms it's a pointer).
> 
> uhhfff.. i am not asking for inheritance from Win32
> handles or pthread_t ids. they are not thread objects,
> indeed. however, they _represent_ objects (internal thread
> objects maintained by the implementation), and you could
> certainly create _inheritable/extendable_ C++ thread _object_
> which would hide pthread_t/handle or whatsoever so that only
> that C++ thread object would know that platform specific "handle".
> everybody else (user program) would simply use C++ ptr/refs
> to C++ thread objects; and yes, you could certainly "extend"
> these C++ ptrs/refs with ref-counting and either join/destroy
> or detach policy. well, please re-check "timed_thread" C/POSIX
> example i've posted a few days ago. it is not C++ but it does
> implement thread object on top of posix thread id.

Too much context has been lost.  The actual context was that _native_ 
thread _types_ can't be inherited.  The point being that it's very 
natural for both users of native types and for C++ programmers to 
extend functionality through means other than inheritance, which 
counters your original assertion.  Yes, we could allow inheritance 
here, but it's simply not a good idea unless there's some virtual 
method you expect to be overriden in derived classes (see the 
recently posted coding guidelines), and the only candidate for a 
thread object would be a run() method, which we both agree is harder 
to use than a function object design.

Bill Kempf
> regards,
> alexander.