Boost logo

Boost :

From: David Abrahams (dave_at_[hidden])
Date: 2005-03-08 09:55:54


"Aaron W. LaFramboise" <aaronrabiddog51_at_[hidden]> writes:

> David Abrahams wrote:
>
>> 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.
>
> I've been thinking about this, but this continues to bother me. Is this
> essentially different from removing the private access specifier from
> the class definition?
>
> It seems to me that, by doing this, we are throwing away so many
> correctness guarantees. To me, this seems sort of like taking
> shared_ptr, and making it implicitly convertable to a pointer. I think
> that promoting this sort of behavior will cause programs that have a
> much lower probability of being correct.
>
> I'd be a lot more happy about a system that forced code that wanted to
> access these internals needed for extension to do something special,
> besides just calling a semi-secret method. For example, derivation does
> this for me--but there might be other ways, that aren't apparent to me
> at the moment.

I can't understand why derivation is any more-special than anything
else. Furthermore, IIUC what you're suggesting, it has
interoperability problems. What do you do if you write a library that
needs to take advantage of some of these platform-specifics, but wants
to traffic in the portable type in its public interface?

This is a simple problem and not worth establishing elaborate
"protection" schemes for. Every C++ user knows there are things you
can do portably, and other things that are platform-dependent. You
can use the C++ standard library portably (for the most part ;->) but
the minute you #include <Windows.h> or <pthreads.h> you're in
platform-specific land. I don't see why this should be any different.

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

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk