Boost logo

Boost :

Subject: Re: [boost] Review quality [ was stack trace review]
From: Robert Ramey (ramey_at_[hidden])
Date: 2017-01-02 17:56:10

On 1/2/17 1:48 PM, Vladimir Batov wrote:
> On 2017-01-03 07:35, Robert Ramey wrote:
>> On 1/2/17 12:08 PM, Vladimir Batov wrote:
>>> ...
>>> The problem with the incubator IMO is that it does not provide any
>>> guarantee whatsoever that the library will be accepted/around/maintained
>>> in the future.
>> No one - not even boost - can make such a guarantee.
> Oh, come on. Of course, nothing in life is guaranteed. I can't guarantee
> I wake up tomorrow morning. But surely we all understand what I was
> trying to say. Is there really anything to debate/discuss here?

Hmmm - actually there is. If you use a boost library, there's a real
world chance that it may stop working in the future. This could occur
because you upgrade your compiler or because someone "improves" the
official version so that it doesn't work for you any longer. Of the
course it's much more likely for something like this to occur on some
other library - in the incubator or otherwise. You seem to suggest that
this is not a problem with boost libraries while it is with others. My
view is that it's a problem with all code and libraries. It just that
due to a higher standard, it may be much less of a problem than it its
with boost libraries.

But my view is that this concern never goes away and this fact should be
built in to the development procedures of any application which depends
on boost or any other library. I don't think that depending on boost or
on some component in the incubator or anywhere else is all that
different. I trust no one.

> I simply described the "real-world" project/product I am involved in.
> I've been doing it for quite some time and as far as I can remember all
> those "real-world" projects were using external libs and Boost has
> always been one of them. Forgive my saying but to say "I do not think a
> real world product can depend on anything outside it's own organization"
> seems very much out of touch with this very real-world... unless I
> misunderstood/misinterpreted it.

Let me clarify. Of course we rely on externally produced code. But if
you ship it, you still have to be responsibility for it. The only way
you can do this now is to run the tests yourself. I realize that people
don't do this and I maintain that they are wrong not to do it. But if
one accepts the view that he should run the tests on every library he
includes in his own product, than the distinction between using a
library review or in the incubator or anywhere else goes away.

> It appears obvious to me that an external lib (local copy or not) is outside of my control...


> unless I am prepared to take responsibility of maintaining the lib... which is not an option.

Unfortunately, you can't evade responsibility for the promises made for
your final product. Hence you can't evade responsibility for the
functioning of the libraries you use. Currently, the only way you can
credibly claim you've fulfilled those responsibilities is to run tests
on the libraries. Libraries in boost and in the incubator are required
to have tests (unlike any other source code collections). So this is
possible in either case.

> With Boost that risk is minimal (practically non-existent); with
> incubator that risk is quite high. Others might disagree.

Certainly one would hope that libraries in boost have fewer bugs. But
since I believe that all code should be tested by myself before I ship
it as part of a product, I can't accept/reject libraries on a case by
case basis. This is what I recommend that anybody do.

Sort of off-topic.

> unless I am prepared to take responsibility of maintaining the lib...
which is not an option.

Actually it IS and option. Take a look at the Boost Library Official
Maintainer (BLOM) program.

If you really depend on some library which no longer has a maintainer,
Your company can take on that responsibility and gain some benefits
besides. The theory is that since you have to run tests anyway and
perhaps apply bug fixes in the normal course of your work, you might as
well take on the job officially and get and inside track in getting your
fixes into the official version and maybe some free promotion/publicity
for your organization.

Robert Ramey

Boost list run by bdawes at, gregod at, cpdaniel at, john at