Rob Stewart wrote:
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.
This is exactly what I would like to see. Boost::thread and other classes should be platform neutral, but provide a method to get at the private handles so that people can extend the class for specific platforms on their own. Another thing I would REALLY like to see is better documentation. I'd love to use more Boost classes, but I don't have time to reverse engineer them to figure out how they work. Chris. __________________________________ Celebrate Yahoo!'s 10th Birthday! Yahoo! Netrospective: 100 Moments of the Web http://birthday.yahoo.com/netrospective/