From: Bob Bell <belvis@pacbell.net>
Another possibility is to provide another level of indirection. For example, boost::thread can have an accessor which returns a boost::platform_thread, which has the OS thread ID, plus member functions which mimic OS operations not reflected in the portable (boost::thread) API. The advantage of this approach is that boost::platform_thread member functions may be able to preserve invariants that otherwise might be broken if the user was allowed to manipulate the underlying OS thread ID itself, and if the coverage of the boost::platform_thread member functions is large enough, it might not even be necessary to expose the OS thread ID at all.
That means that everything possible on a given OS should be provided -- ultimately, anyway -- but at least it would be done once, right, and safely. I like it. The concern is how that type is related to the portable type. If it is to maintain invariants, it has to know a great deal about the portable type. Perhaps it could contain a (reference to a) special type derived from the portable type that provides access to more implementation details/APIs that enable it to maintain invariants while it offers an expanded interface. -- Rob Stewart stewart@sig.com Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;