Boost logo

Boost Users :

From: Jim Douglas (jim_at_[hidden])
Date: 2006-02-04 06:18:01

David Abrahams wrote:
> Jim Douglas <jim_at_[hidden]> writes:
>>David Abrahams wrote:
>>>Jim Douglas <jim_at_[hidden]> writes:
>>>>IMHO it is high time that someone produced a dependency graph, or each
>>>>library document had a "uses" section.
>>>Do you know about and its
>>>--report option?
>>I am aware of it, but the output is not very user friendly
> I agree with that. John, do you think it would be possible to
> generate a simple list of boost library dependencies, e.g.
> parameter depends on mpl, type_traits, config, utility, and preprocessor

With a bit of additional scripting that would be possible now.

>>and AFAIK you
>>cannot decouple the test functions to show what is required for "normal"
> I don't know what you mean there about the "test functions"

If you run bcp, every library shows up as depending on test and mpl
(because test uses mpl). Boost.test is only used for regression testing.
When you deploy a Boost library in a project, Boost.test is no longer of
any use/interest, but the chosen library may still depend on others in
the suite.

What we need is the ability to take Boost.test (and its dependencies)
out of the equation so that we can see what the dependency graph looks
like when the individual libraries are deployed.

>>>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.

IIRC when the laser was invented it was described as "A solution looking
for a problem". I guess you could apply that to Boost as "A bunch of
general purpose solutions looking to solve specific problems". Some
variation of that theme might make a good Powerpoint slide for your
presentation :-)

>>>>4. The single word naming of the libraries can lead to ambiguities and
>>>>misunderstanding e.g. "serialization" means different things to
>>>>different people and requires a full paragraph to explain, and IMHO
>>>>"thread" is somewhat misleading. Other names mean nothing to me so I
>>>>have to go and look them up.
>>>What would be better, "the boost serialization of a style espoused by
>>>Robert Ramey library?" ;-)
>>LOL. But I think you get what I mean.
> Really, I don't.

OK a really good example is "signals". To a Unix/QNX programmer a signal
has a very specific meaning, and for a while I didn't bother to look
further because I assumed that Boost.signals was basically a set of C++
wrappers around the Unix functions (same applied to Boost.threads). It
wasn't until I read the Karlsson book that I realised they were quite

That's the problem. I'm not sure of the solution - but I think we have
floated some useful ideas...


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