Boost logo

Boost :

From: David B. Held (dheld_at_[hidden])
Date: 2002-04-10 18:39:01


"Jonathan H Lundquist" <jhl_at_[hidden]> wrote in message
news:16A76C30B159844FB300DB9DC474A89F0D87B4_at_ruby.sssonline.com...
> > Personally, (this isn't meant to be a generalisation) I don't care
> > what the implementation looks like. I don't care if the idioms
> > under the hood fit naturally to the language or not. I do care
> > whether it's (comparatively) easy to learn and easy to use,
> > and whether it supports all the things I want to do with it.
>
> This is a commonly cited criterion, based on the holy-grail of reusable
code
> being only a matter of understanding the interface. However, in
practice -
> if I can't get my mind around it (*the implementation*) I won't allow it
in
> my process space. For me that's just basic defense. [...]

Fortunately, I'm not limited by this philosophy. I regularly use
boost::bind,
boost::function, and boost::smart_ptr with only the vaguest notion of how
they
are implemented. When something goes wrong, I don't look at the source,
I look at the documentation, and see if I'm doing something the library
wasn't
intended to do. I have taken a brief look at the source for all of those,
and
the smart_ptr implementation is the only one I feel I could really
understand,
given some time and effort. But this has not prevented me from using these
libraries effectively and enthusiastically. An even better example is
Spirit,
which is absolutely opaque to my understanding, and yet is so powerful,
I am compelled to use it rather than wasting time duplicating it's
functionality.
I also use the STL containers regularly without knowing how they are
actually implemented in whatever vendor's library I am using. I suspect
that this is true for most people. Have you ever looked at the code for
STLport? ;)

Dave


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