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

Subject: Re: [boost] 5 Observations - My experience with the boost libraries
From: vicente.botet (vicente.botet_at_[hidden])
Date: 2010-03-23 16:57:36

Hi,
----- Original Message ----- 
From: "Tom Brinkman" <reportbase2007_at_[hidden]>
To: <Boost_at_[hidden]>
Sent: Tuesday, March 23, 2010 7:11 PM
Subject: [boost] 5 Observations - My experience with the boost libraries

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

I think that C++ developers need to understand how exceptions works. If you dont 't reach any member of your team understand correctly that you should compile without exception support.
 
> 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.

Iostream stry is safe. I have worked on a lot of projects having a lot of bug in printf like functions on site. I prefer the compiler give me these kind of errors for safety purposes.
 
> 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.

I don't agree Boost goal is to provide any C/C++ developer could use. I see Boost as a collection of libraries that show how people can use the high level C++ language and not only the low level.
 
> 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++".

I will not say pure "C++", just practical 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.

Do you mean that you dont use any library that uses Boost, any product that uses Boost?

I think that your or your leader are following a wrong reasoning.  You can forbid the direct use if you have good reason, but I dont see why forbid the use of products that use this Boost library. I don't know which libraries you dont want any member of your project to use and why, could you tell us more?

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

I think that this is an educational issue. If you have a good reason to not use a library you should be able to share this with the developers.

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

Could you talk about the obious reason?
 
> 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.

Boost is what the Boost community want Boost to be. If more people want other style of programming, they can make concrete proposals, participate on the reviews, showing how they think Boost must be.
 
> 4) Many boost libraries seem more like they research projects.  The
> prevailing
> view is that boost libraries push the envelope of what is possible.

Could you give some examples of research projects?
 
> 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.

You are right. Any booster works hard to provide wht he thinks is his day to day needs.
 
> Experience proves otherwise.
> 
> The practical needs of large scale active projects are in conflict.

Could you be more explicit. Which needs are in conflict?
 
> Boost is very dogmatic and encourages a particalular style of development,
> which is very template based.

Templates allows to program using the generic paradigm, and Boost make use of this quite often. Which style of developement would you want?

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

Well it is think quite different to make a  generic library that using it. You don't need to spend many more iterations to use a generic library.

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

The fact you have not succeded do not menas that other have not succeed.
 
> That being said, boost::mpl and boost::spririt are wonderful accomplishments
> 
> and I use them regularly.

Here there are two examples of the most complex libraries in Boost, and surely betwenn the more useful on a given context.
 
> 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.

For most of the cases the use of PP is to emulate variadic templates. So this is temporary until all the compilers will support variadic templates. Let me say, for 2015.

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

I don't think this is true. Any Boost library can be maintained by some other than the author. Of course this will need a deep understanding of what and how this is done. I have used a lot of C libraries, and I will need also quite a lot of time to maintain the library.

I think that any entrepise using C++ and Boost should have a C++ expert that guide the complete team to adhere to the best practices. This people could be the one that could maintain the library if the author don't do that.
 
> 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 expect to have an idea of what a library is doing by reading its documentation, not examining its code. If a library is not enough documented we shoudl make requests to the documentation.

Best,
Vicente