Kevlin Henney wrote:
Although Boost.Threads uses templates in expressing some of its capabilities, it is a relatively closed design wrt extension, and hence not what would normally be termed generic.
A partial list of features I expect in the documented interface of an open thread library: 1) Ability to define my own thread implementation that is compatible and cohesive with the included implementation 2) Ability to use more than one implementation at once in different parts of the code. (For example, on Cygwin, you could conceivably use POSIX threads and Win32 threads in the same application.) 3) Ability to extend the existing implementations to take advantage of underlying features of the threading implementation that may require private thread handles 4) Cohesiveness with arbitrary demultiplexors. (For example, there should be some adaptor that lets me wait for threads in an application based on the popular libevent library.) 5) Ability to dynamically load any of the above parts after execution has started, so arbitrary implementations might be provided (possibly for some additional penalty). Related to #3 above, I am wondering what the standard committee's current feeling is on providing some way for user code to access inner handles of standard library abstractions. Of filebuf, this is a fairly common request. I've been thinking about Dave Abraham's suggestion <http://lists.boost.org/boost/2005/03/21839.php> that theres no reason to provide a special protection mechanism for these inner handles. The feeling I get from many here is that you should be able to hit a red button, such as including a special implementation header, and you're back in shoot-yourself-in-the-foot land, with the confidence that "the programmer knows what he's doing." I've decided that this is not compelling for me. We always know what we're doing--we're superheroes, we're C++ programmers. Yet C++ is partly about letting us define a set of rules for ourselves, to catch our mistakes, and keep us honest. I think the ability to hit this red button and suddenly have full license to blow away a class's invariants without any of the traditional protection mechanisms is downright barbaric. I think there *is* something special about inheritance. The "protected" keyword gets wonderful milage in other application domains, and I have no idea why system abstractions need to be any different, such that for system dependence, its perfectly acceptable to revert to pre-Dijkstraesque programming practices. Certainly noone would tolerate this additude with other well-defined standard libraries: no matter how much you beg, you just aren't going to get anyone to give you a pointer to std::list's linked list head. People point out that shared_ptr can be persuaded to give up it's pointer, to let the programmer do what he needs if required. However, this isn't the same; the pointer isn't actually part of the implementation. For example, you'll never be able to directly manipulate its reference count, even if you pull rank and flash your system-specific badge. Maybe inheritance isn't the right mechanism. But I think there should be something that isn't as heavy-handed as just giving up and stripping down. I think that once an acceptable mechanism is invented, it could be applied across the board to not just thread, but std::filebuf, boost::filesystem, sockets, and other similar components. Sorry for the length, Aaron W. LaFramboise