Boost logo

Boost :

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.

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