From: David Abrahams <dave@boost-consulting.com>
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.
Exactly what I was thinking. That's all it takes, but you don't want to make it syntactically quiet to get at the underlying OS-specific data. IOW, you want something akin to the new-style casts in verbosity so the switch to non-portable code is loud and clear. Doing that via a derived class is one way. Using a cast to the OS-specific type within the portable facade is another. (The latter doesn't introduce polymorphic side effects such as call overhead or slicing.) boost::whatever w; special_type s(boost::platform_cast<special_type>(w));
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.
If the platform specifics are kept from the portable interface -- through implementation magic -- then we get both properties. Documentation must also mention what not to do via that non-portable mechanism. IOW, there are many things one can do via low level APIs that can break invariants, so restrictions must be placed upon what can be done or more interface is needed to allow the portable interface to adapt to the effects of the non-portable code path. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;