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

Subject: Re: [boost] 5 Observations - My experience with the boost libraries
From: Tom Brinkman (reportbase2007_at_[hidden])
Date: 2010-03-23 17:43:53

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

Not true, there are no-throw versions of std::new.

In any event, my point is that c++ exception handeling should be optional.
Boost libraries need to be updated to reflect this.

One of the first thing that comes up when a mixed language C/C++ project
uses a C++ library is: Does this library throw exceptions?

Generally and unfortunately, if the answer is yes, that library will be
ignored out of hand.

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

This is a real issue.

Boost.format is not a replacement for Printf -- they have different
syntaxes.

Printf style arguments are the prevailing api style.   No one is asking for
printf style
arguments to be replaced.  Why replace something that is the standard and
works just fine.

This is just symptomatic of my larger point that boost is a research project
and not relevent to day to day C/C++ programmers.  Why replace something
that is universally adopted and works just fine.

If boost developers want to create an alternative to printf, that is fine.
However, it should be just that, an alternative, not a replacement.

Printf style api's are easy to implement.  There are reasons not to do them.

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

It can absolutely be an issue if one of the dependent libraries throws
exceptions for example.  Because boost does not have clearly stated policy
about exceptions, who knows what changes occured between versions.

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

This is a key issue.  Because boost does not allow you to choose only select
libraries,
you must use all of boost.  And because there are no clear guidlines
regarding exceptions and policies, it can be scarey to know what exactly is
going on.

Project prefer safety to features.  If the risks of using boost are unclear
without is clear policies about exceptions and depencies, its  easier to not
use boost at all so its abandoned in its entirety, no matter how much you
want to use a specific library.

>