[boost] Re: What I Hate About How We Abstract System Dependence

From: David Abrahams (dave_at_[hidden])
Date: 2005-03-07 08:56:28

"Aaron W. LaFramboise" <aaronrabiddog51_at_[hidden]> writes:

> Mathew Robertson wrote:
>
>> I'd argue that we know exactly - no more, no less -> either the
>> operating system supports a capability, or it doesn't. The only
>> real question is, 'when do we detect the capabilities,
>> at build time? at run time?'
>
> I think we need more granularity than this.  One important
> counterexample is the case when a capability may be enabled while the
> operating system is running.  For example, a driver may be loaded that
> presents a high-quality random number source.
>
>
>>>Here’s another one of my favorite examples, in Boost.Threads
>>>(“Boost.Threads,” <http://www.boost.org/doc/html/threads.html>).
>>>boost::thread lacks a method to forcefully terminate a thread, despite
>>>the fact that many threading systems have one.
>> 
>> So most people go with an implementation that does not provide forcible termination.
>
> OK.  I'm not concerned with this particular feature, but the fact that
> there will always be some feature that the system supports that a user
> may want that Boost.Threads will not implement.  If its not this, then
> it might be thread priority, and if not that, then it might be setting a
> thread's processor affinity, or who knows what else.
>
> My point is that the concrete Boost.Thread is not open for extension.
> If you want a feature it doesn't provide, you either have to modify the
> sources, or just write yourself an entirely new thread ibrary.  This is
> should not be the way we do it in C++.

I have always thought that concrete implementations of portable
libraries should supply users a way to get at the OS-specific data so
they can use platform-specific facilities on them if neccessary.

You have to understand, the Boost.Threads specification was designed
to become a standard, and as such it didn't include anything
nonportable.  That said, there's no reason we shouldn't expose the
low-level thread IDs and document them in a special section on
platform specifics.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com