"Aaron W. LaFramboise" <aaronrabiddog51@aaronwl.com> 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