Boost logo

Boost Users :

From: David Abrahams (dave_at_[hidden])
Date: 2006-02-04 18:35:52

Jim Douglas <jim_at_[hidden]> writes:

> 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

I don't think so. When I tried it yesterday there was no mention of
Boost.Test headers in the Boost.Parameter dependency report.

>>>>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 preprocessor library has a pretty good (if I do say so myself)
tutorial with a real-world example in it.

> 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 :-)

No thanks. Boost libraries are very nicely targeted at specific
problem domains.

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

Fine, but serialization and threads? C'mon.

Dave Abrahams
Boost Consulting

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