Boost logo

Boost Users :

From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2006-02-04 07:56:53

> -----Original Message-----
> From: boost-users-bounces_at_[hidden]
> [mailto:boost-users-bounces_at_[hidden]] On Behalf Of Jim Douglas

> [...]
> >>>Yeah... some libraries are so general-purpose (e.g. lambda, mpl,
> >>>preprocessor) that it's hard for me to say anything that
> most people
> >>>will identify as their use case.
> >>
> >>Does *anyone* use them?
> >
> > Yes, many people use them.
> OK I was being slightly flippant, but some examples of would
> help identify use cases for those particular libraries.

The problem is that these libraries--particularly the MPL and the pp-lib--are
general-purpose to the point of being language-like rather than library-like.
Enumerating use cases for these libraries is like enumerating use cases of
looping or branching. Listing several use cases doesn't even slightly do
justice to the underlying concepts, and they become nothing more than complex

IMO, the approach of trying to solve a particular problem, searching for a
library that solves (or helps to solve) the particular problem, and expecting to
find one of these types of libraries is flawed. It works the other way around.
Instead, you invest the time necessary to understand what kind of things these
libraries can do, etc. (which doesn't imply mastering the library). Later, when
you evaluate possible solutions to a particular problem, you often have more
realistic possibilities because these libraries remove design limitations that
would otherwise cause you to reject a possibility. Because of that, real-world
use cases of these libraries are usually completely unrelated to what these
libraries do. The libraries themselves are just used to implement "something
else" that otherwise couldn't be easily implemented.

(I'm having a hard time formulating what I'm thinking, so perhaps I'm not
describing what I'm trying to get at very clearly.)

Any given interface falls at some point between completely specific to
completely general. An interface that is completely specific has only one
specific use case. Such an interface is not a _library_ interface. An
interface that is completely general has an infinite set of use cases that
covers an infinitely broad scope. Such an interface cannot exist. Libraries in
Boost vary greatly in where they fall along this specific->general axis. The
more general a library is, the more difficult it is to describe the library in
terms of use cases. When a library approaches being completely general,
effective use requires a significant amount of lateral thought by the user, not
use cases in the documentation. Examples (as opposed to use cases) in the
documentation exist mainly as an attempt to induce the necessary lateral
thought, not to show what problems the library solves.

Hopefully, that made any kind of sense. I've given this a lot of thought over
the last several years for the pp-lib docs, as this is a typical complaint ("The
docs don't tell me in what situations the library is useful."). I still don't
know what I could write to do that, and, at this point, I'm starting to think
that attempting to do that is counterproductive.

Paul Mensonides

Boost-users list run by williamkempf at, kalb at, bjorn.karlsson at, gregod at, wekempf at