Hi Aaron, Just a quick comment: while your complaint is a reasonable and relatively common one, and while I think your proposal for introducing more granularity by way of deeper inheritance and factory methods is well-reasoned, there are two issues that still prevent me from agreeing with your approach. The first is the attitude of "a user shouldn't have to pay (too much) for what she's not using." That's a far cry from saying "a user shouldn't have to pay AT ALL for what she's not using" because, in my opinion, you're gambling that for all domains to which your proposal applies -- not just threads, but file IO and so forth -- the penalty you pay for virtual pointer indirection at a minimum, and perhaps the dynamic_cast<> or typeid() operations, or even exception handling, is negligible in comparison to the performance cost of the abstracted operating system functionality itself. You're furthermore gambling that RTTI or exceptions are even available (or, if available, appropriate) to use on all platforms: while admittedly embedded systems programmers may already have only limited use for Boost, I'd hesitate to add this additional prohibition. My second issue with your proposal is the coding style it demands. Have you had the joyous experience of working with COM? You're essentially proposing a QueryInterface work-alike. But the legalese and boilerplate code required for even the simplest of tasks in COM is, in my opinion, entirely anathema to the elegance of Boost's libraries (particularly boost::thread, which I felt was a godsend when I first encountered it!). And whether you choose to implement your QueryInterface in a way that selects implementations at compile time or at runtime, developers using your implementation run into one of two typical code-clutter issues: If the selection is done at compile time, developers of cross-platform code must set up a series of #ifdefs that are perfectly in sync with the functionality Boost would have elected to provide on each platform. If the selection is done at runtime, you get into the business of providing GUIDs to identify interface and implementation versions at best, or forcing use of RTTI at worst, which reflects back to the developers as unnecessarily complicated client code. So as much as I'd like to see better representation of non-portable features in Boost, this is a problem whose solution I still consider fleeting. Cheers, dr On Sun, 06 Mar 2005 19:29:09 -0600, Aaron W. LaFramboise <aaronrabiddog51@aaronwl.com> wrote:
Over the past few years, the style of our abstract interfaces for system-dependent features has bothered me more and more. [snip]