From: David Abrahams <dave@boost-consulting.com>
Rob Stewart <stewart@sig.com> writes:
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.
I think that's much too fancy. Put a free function to access the platform-specific data in a separate header and you're done.
special_type == platform-specific data platform_cast == free function What's "much too fancy" in my suggestion? I didn't mention a separate header, but there's little difference otherwise. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;