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

From: Dan Rosen (dan.rosen_at_[hidden])
Date: 2005-03-07 11:48:47

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_at_[hidden]> wrote:
> Over the past few years, the style of our abstract interfaces for
> system-dependent features has bothered me more and more. [snip]