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

Subject: [boost] 5 Observations - My experience with the boost libraries
From: Tom Brinkman (reportbase2007_at_[hidden])
Date: 2010-03-23 14:11:38

Over the past years, every project that I have been involved with
has tried and then either abandoned boost or highly restricted its use.

As a long time boost user, I can't tell you how much debate we've had about
this.

I want boost to succeed, grow and be successful. Its sad.  As someone who
has used boost
from the beginning, and has taken far more than I have given, here are some
of my observations.

Many of the reasons don't have specifically to do with boost, but more have
to do with a preference for one programming style versus another.

I have identified 5 key issues about why boost was abandoned.

1) Boost uses exceptions.
2) Printf versus Iostream.
3) Dependencies.
4) Research Projects
5) Macros

1) Boost uses exceptions.

This issue is best illustrated when you want to just do something as simple
as converting a
"string" to an "int".   boost::numeric_cast throws an exception, which
forces you to wrap
it into a try-catch block.

The seemingly trivial issue of how to handle exceptions causes endless
grief.
It seems that developers still prefer "C" style casts.

The prevailing view on projects that I have worked on is that C++ exception
handling should optional and
not required.

int value = 0;
try {value = boost::numeric_cast<int>("3.00");}catch (...){}

versus

int value = atoi("3.00");

I think the lesson is that there is no correct answer here.  As most "C++"
projects use
some "C" libraries, you will need to be flexible in your approach to
exception handling.  A pure "C++" approach
of try-catch blocks is not practical.

As boost libraries tend to throw exceptions, it forces you to put try-catch
blocks
all over your code.  Many developers will simply ignore this issue and end
up
with lots of code that is not exception safe.

Small issue, but is undoubtably a source of a huge amount of problems.

2) Printf versus Iostream.  Most developers still prefer "printf" over
"iostream" style "api's".
Unfortunately, Boost libraries have long ago adopted "iostream", as the
preferred API style.

This issue has been the source of many hours of needless debate.  Pure C++
developers seem to have a aversion
to "printf" style arguments.  As there are very few pure C++ projects (if
any), I dont hear about this
as much as I once did.  Most C/C++ developers prefer a printf style api.

Boost needs to start providing printf style api's.

Boost needs to be more practical.  By not also providing printf style api's,
boost is not
meeting the needs of developers.

Iostream may be preferable for purely academic reasons, but for practical
reason, "printf"
is the api style that is universally adopted.

Is it boosts goal to meet only the needs of a small subset of its c++
users?  If that is the
goal, than it needs be clearly stated as such.

As most developers have adopted a combined C/C++ style of development,
a pure academic C++ style syntax is not practical for every day use.

Boost needs to look at what the popular api styles are and adopt them and
not be
so dogamtic about its style of so-called pure "C++".

3) Dependencies.

Everyone has a few favourite boost libraries.  Unfortunately, because of
confusing
dependencies between them, 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.

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.

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.

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.

The way boost was developed makes this practically impossible.

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.

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.

Experience proves otherwise.

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.

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

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.

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

That being said, boost::mpl and boost::spririt are wonderful accomplishments

and I use them regularly.

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.

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?

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.

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.

Tom Brinkman