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

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

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
www.boost-consulting.com