From: Rob Stewart (stewart_at_[hidden])
Date: 2005-03-07 21:23:20
From: David Abrahams <dave_at_[hidden]>
> Rob Stewart <stewart_at_[hidden]> writes:
> > From: David Abrahams <dave_at_[hidden]>
> >> 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_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