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

Subject: Re: [boost] 5 Observations - My experience with the boost libraries
From: Stewart, Robert (Robert.Stewart_at_[hidden])
Date: 2010-03-23 14:45:59

Tom Brinkman wrote:
>
> I have identified 5 key issues about why boost was abandoned.
>
> 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.

Exceptions are a fact of C++ life.  You can't avoid them if for no other reason than std::bad_alloc, unless you don't allocate from the free store.

Having said that, they are often overused or too infrequently made optional.  Boost.System is fairly recent (and being standardized) and bug reports against other libraries could encourage conversion to its use (or to similar techniques) to make exceptions optional.

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

If all you care about is best effort string-to-int conversion and zero is fine if no conversion is possible, then atoi() is better.  Typically, however, one should exercise a bit more control.  Whether that control requires exceptions is, in some measure, a matter of taste.  strtol() and friends try to do things better, but one must carefully examine the return value, end pointer, and errno value to correctly determine whether the conversion succeeds.  I usually prefer to get an exception from code that has done all of that troublesome effort unless *profiling* shows the overhead is significant.

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

You are forced to wrap code that can emit exceptions only if you wish to ignore them or must translate them into error codes for some other code.  Otherwise, you must face reality and properly account for the exceptions.

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

Boost.Format provides what you want.  There's relatively little output from the various libraries, so I don't see where this issue arises in real use cases.

> Boost needs to start providing printf style api's.

As an example, Boost.Log, just up for review, provides support for Boost.Format as well as IOStreams.

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

Boost is clearly targeted toward advanced uses of C++ and standardization.  Nevertheless, I agree that there's no reason to alienate those who like printf()-style I/O.

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

The dependencies aren't confusing so much as complex.  Would you have each library in Boost reinvent rather than reuse other Boost functionality?  Isn't that the point of Boost libraries: reuse functionality written by others?

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

I don't see why dependencies among Boost libraries would lead to picking and choosing which are approved.

> It seems that once you add boost to your project, some
> developers feel that you should be able to use any part of boost.

Ah, you actually meant that project leads wish to constrain which parts of Boost may be used but because of the inter-library dependencies, much more than wanted must be allowed.

> The way boost was developed makes this practically impossible.

You're welcome to contribute patches where you think such dependencies can be reduced.

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

I don't think Boost "pretends" to be much more than that.  Many understand that there are no guarantees as to performance, compatibility, etc. among Boost libraries.

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

Boost aims to be a proving ground for practical research, frequently en route to standardization, with the intention of solving real needs.  It has never pretended to be a collection of libraries to be used where long term maintenance and stability are important.

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

Boost is not dogmatic about whether a library uses templates.  It just happens that a lot of problems can be solved really nicely using templates and they are interesting to the volunteers who submit libraries.

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

Why should you care about that?  If you can't stomach an unstable library, don't use it until it has baked a while.

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

I find template code to be a pain when things don't go right, but a real boon when they do.  I use templates, whether my own or from libraries such as in Boost, within my code to support others.  I control how much template code is exposed to others.

> That being said, boost::mpl and boost::spririt are wonderful
> accomplishments and I use them regularly.

Hmmm, that means that template-based code is a good thing.  Perhaps you can be more specific about your problems and avoid generalities.

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

That simply points to the ignorance of those developers then.  Boost is multi-platform and must account for myriad differences.  Yes, this is in large part because Boost tries to push the envelope, but just have a look at the source for GCC and other portable projects.  Boost isn't alone in such macro-controlled configuration and workaround code.

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

Write once code is easy to create, of course, but if you can't grok what's in a Boost library, then don't bother.  Treat it like a black box.

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

You write to the interface and if the library provides useful functionality, you're golden!

> 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 don't understand why a library is "very dangerous to use" if you can't understand its implementation.  That just suggests that you want Boost to be dumbed down for some arbitrarily low experience level.

I understand that template heavy code is a real burden for many to understand and use.  Templates are an entirely different language within C++ (and they can be used to create still others -- DSELs).  Some don't care to learn that language.  Fine.  Why should Boost avoid them to satisfy those that don't care to learn templates that well?

There are certainly things that can be done to make Boost more accessible to more people.  I'm sure all library authors will welcome constructive input from you and others with your concerns.  (I expect patches will be still more welcome.)  I hope that you review all submitted libraries and make comments on how they can be simplified, how template usage can be reduced, etc., in order to try to steer future Boost libraries along the course you prefer.  Discussion is always helpful to hone designs and interfaces.

_____
Rob Stewart                           robert.stewart_at_[hidden]
Software Engineer, Core Software      using std::disclaimer;
Susquehanna International Group, LLP  http://www.sig.com

IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.