Re: [boost] Re: What I Hate About How We Abstract System Dependence

From: Rob Stewart (stewart_at_[hidden])
Date: 2005-03-07 11:53:53

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.

Documentation must also mention what not to do via that
non-portable mechanism.  IOW, there are many things one can do
via low level APIs that can break invariants, so restrictions
must be placed upon what can be done or more interface is needed
to allow the portable interface to adapt to the effects of the
non-portable code path.

-- 
Rob Stewart                           stewart_at_[hidden]
Software Engineer                     http://www.sig.com
Susquehanna International Group, LLP  using std::disclaimer;