Re: [Boost-users] Getting started with Boost: what did you need to know?

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 http://www.boost.org/tools/bcp/bcp.html 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" 
>>use.
> 
> 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 
different.

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

Jim