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

Subject: Re: [boost] 5 Observations - My experience with the boost libraries
From: Gennadiy Rozental (rogeeff_at_[hidden])
Date: 2010-03-23 18:12:45

Tom Brinkman <reportbase2007 <at> gmail.com> writes:

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

My general comment to this post is In my personal opinion you are overgeneralize
your experience. My experience, while having some common points is rather
different in many other aspects. 
 
> 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.

You probably meant lexical_cast.
 
> The seemingly trivial issue of how to handle exceptions 
> causes endless grief.

I must admit I had 1 or 2 instances where I would have welcomed more graceful
interface for lexical_cast, but in 99 of other places I use it I expect error to
be an error.

> It seems that developers still prefer "C" style casts.

Not in my experience and I discourage anyone on my team from using them.
 
> The prevailing view on projects that I have worked on is that C++ exception
> handling should optional and not required.

Umm... why? Performance?
 
> 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.  

I think the lesson is that exceptions should report *errors*. If you tend to put
try/catch around the function invocation, that means interface is incorrectly
designed and in some cases you want to deal with error condition right there. I
do agree that some of the interfaces we have might exhibit the issue though.

> A pure "C++" approach of try-catch blocks is not practical.

try-catch blocks is pure Java approach. In C++ you should not have many of these
in your application code.

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

RAII + boost::execution_monitor allows me to avoid most of them.

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

Not in my experience. I personally dislike all these woodoo strings and strive
to stay away from them as far as possible.

> Unfortunately, Boost libraries have long ago adopted "iostream", as the
> preferred API style.

C++ adopted it long ago. Boost developers follow the suite.

> 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.Format does allow one to use printf like statements. Though unless you
have internationalization requirements, I personally  do not see a reason to
prefer one (I know of course some who do).

Otherwise I am not sure what you mean. You need to show specific examples.
 
> 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.

In most of the project I worked for last 10 year we moved away from the printf
like api.
 
> 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.

I think you are overstate the problem. There are number of core components
almost definitely required, but there are many many others which can be easily
split.

> 4) Many boost libraries seem more like they research 
> projects.  The prevailing view is that boost libraries 
> push the envelope of what is possible.

You've got couple options as I see it.

1. Don't use these
2. Stick to one version which works and use it.
3. Maintain one yourself.

What is not an option *in general* is to tell the library author: "Do not make
any changes".

That said I concur that we need to have "grading" in boost libraries. Some
should be graded as "production-ready", some "in-development", some "candidate".
First section is disallowed to make backward incompatible changes and thus cna
be safely used in production environments.
 
> Unfortunately, boost pretends to be something else.  It pretends to be
> a collection of libraries that meet your day to day needs.

I do not believe boost pretends to be anything. You can't make this general
statement about something being developed in 90 different directions.

> Boost is very dogmatic and encourages a particalular style of development,
> which is very template based.

I do not believe I agree with this statement. At least not in full. I do see
some instance of template overuse, but I see many others where templates are
right on a spot.

It  might help if you cna show some concrete examples.

> 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

If you are using mpl and spirit in your production code I can't see other
template use cases to be much more advanced.
 
> 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.

Are these macros part of public interface? If yes, that might indicate the
issue. Though There are number of reasons why this is the case. Take Boost.Test
for example.
  
> However, many developers question the value of a cutting-edge template
> library that is full of macros.

I am not. I have very good respect to the PP and all that it can do for us.
 
> 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?

Definitely not for that reason. The unit tests and documentation should serve
this purpose.

> What is the practical value of a library that can only be maintained
> by the original developer(s)?

My (slightly extreme) position is that this is exactly right thing to do. In
many cases the amount of work necessary to make the code maintainable by any
developer way exceeds the benefits. You document every function and every if
statement, describe some implementation decisions and performance considerations
and still new guy make some silly mistake.
 
IMO we are putting too much value into implementation. Keep the interface and
unit tests, and spend some time to rewrite the whole thing, so that new
developer knows it as his 5 fingers.

This is not an absolute rule, but makes sense in many circumstances.

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

I do not know how most boost libraries I am using work inside. And I sleep well
somehow. ;)

Gennadiy