Re: [boost] 5 Observations - My experience with the boost libraries

Subject: Re: [boost] 5 Observations - My experience with the boost libraries
From: Markus Werle (numerical.simulation_at_[hidden])
Date: 2010-03-25 19:37:36

Tom Brinkman wrote:

> 3) Dependencies.

>  its practically impossible to isolate the ones
> you want from
> from the ones you don't.
> 
> What does this mean?
> 
> Well, it requires the leads of a given project to create a policy about
> which boost libraries are approved and which ones aren't.

I agree we have a dependency jungle problem within boost.

> Because of the difficulty of doing this, after a while, its can become
> eaiser to just say "screw it". We won't use boost at all.

OTOH if the great benefit of using some boost library is not obvious to the 
project lead and the lead "screws" it just because of defects within the SD 
process (no review?) and team communication isssues then the lead should 
change and not boost.

> This issue may seem trivial, but it is the cause endless hourse of grief.
> 
> It seems that once you add boost to your project, some developers feel
> that you should be able to use any part of boost.

AFAICS there are not too many C++ libraries around that can compete those in 
boost. Most of the times the boost version is superior.
So "if in doubt, take it from boost" is probably a GoodThing. 
I do not see a problem here.

> For obvious reasons, project leads prefer to have control over which
> libraries are used in a given project.  Few will just give blanket 
> approval to all boost libraries.

I prefer a pragmatic approach here: Grab something from the internet,
try to use it, check if library is actively maintained and estimate the 
chance this will be so for a while. If it works, make a code review and 
if no issues are risen, go on to the next problem.  

> The way boost was developed makes this practically impossible.

Come on: 

a) Install a wiki on the intranet (5 to 55 minutes, depending on OS)
b) copy the list of libraries from http://www.boost.org/doc/libs (3 minutes)
c) add allowed/disallowed tags to all of them (1h, further discussions 
later)
d) send email to team with link to wiki page (5 minutes)
e) kill people during code review who do not adopt the rules (1 second)

What kind of project leads are you working with?

> Boost needs to advertise itself correctly and not pretend to be something
> its
> not.  Its simple a place for promising research libraries to live, to get
> some exposure,
> and possibly be adopted by the larger C/C++ community.

No. Most boost libraries are pre-stage for an industry standard.
No one is pretending here. They are serious about this.

> Currently, boost provides the best place to do that, but it needs to be
> honest with its users.
> 
> 
> 
> 4) Many boost libraries seem more like they research projects.  The
> prevailing view is that boost libraries push the envelope of what is 
> possible.
> 
> This is universally considered a good thing and it is always interesting
> to see what the best and brightest are up too.
> 
> Unfortunately, boost pretends to be something else.  It pretends to be
> a collection of libraries that meet your day to day needs.

For me that is exactly what boost does. 
 
> Experience proves otherwise.

Not for me.

> The practical needs of large scale active projects are in conflict.
> 
> Boost is very dogmatic and encourages a particalular style of development,
> which is very template based.

Modern C++. Yes. Not less than that for good reasons.

> In the right hands, a heavy templated based project can work.

No. That is not the point. Templates are used in order to obtain an 
extremely high level of abstraction while not sacrificing performance. 

Something like 

  Solver.AddPDE(ddt(rho) + ddx(rho*u) == 0);

where the PDE is disasembled at compile time (!) and all its components
are differentiated with regard to all variables again at compile time and 
the solver solves the problem within the theoretically achieveable minimum 
time.

> In my experience, however, it takes many many iterations to get a template
> based designed library correct and usable.  Many more iterations, in fact,
> than the equivalent non-template design.

Proof is missing here.

Could you please rewrite boost::spirit without templates?
Could you please rewrite boost::function without templates?
Could you please rewrite boost::lambda without templates?

> It is soo difficult, that I am very reluctant to use others template
> based libraries.  I approach them with fear.

Boost libraries or code outside of boost?
Again my impression: it is more an issue of 
Modern C++ vs. Baby C++
 
> That being said, boost::mpl and boost::spririt are wonderful
> accomplishments and I use them regularly.

So fear depends on author?
> 
> 5) Macros.
> 
> Need I say more.  The core boost libraries are full of macros.  So much
> in fact, that close examination makes many of them practically
> unmaintainable.
>
> I know there are practical reasons to use them.
> 
> The main reason being compiler inadequacies.
> 
> However, many developers question the value of a cutting-edge template
> library that is full of macros.

Value comes from usability. Do you judge a car by how you can drive it or 
not?

Platform independence has its price.
If you do not want to pay for it, then ... shrug.

> What is the point of having the source code, when it take an experienced
> developer many weeks to understand what the library is doing underneath?

Maximum Portability. Usability. Performance.

> What is the practical value of a library that can only be maintained
> by the original developer(s)?
> 
> This issue has surprised many, but has comes up often.

Good Point. There are efforts to collect all the dirty tricks.
A good start is: 
http://www.amazon.com/exec/obidos/ASIN/0201734842/
http://www.artima.com/cppsource/foreach.html
 
> If it takes more than a day to examine a libraries source code and
> have some idea what its doing, its very dangerous to use.  This issue
> will cause many to avoid complex templated macro-style boost libraries.

I do not get this.
It never takes more than an hour to get the key point of a boost library 
after reading the docs. C++ is not Knuth literal programming.

Markus