|
Boost : |
From: Rob Stewart (stewart_at_[hidden])
Date: 2005-03-07 21:31:28
From: Bob Bell <belvis_at_[hidden]>
>
> 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_at_[hidden] Software Engineer http://www.sig.com Susquehanna International Group, LLP using std::disclaimer;
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk