"Aaron W. LaFramboise" <aaronrabiddog51@aaronwl.com> 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