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

From: David Abrahams (dave_at_[hidden])
Date: 2005-03-07 12:44:41

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.

> 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.

Of course.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com