Re: [boost] Use of boost in safety critical work

Subject: Re: [boost] Use of boost in safety critical work
From: gast128 (gast128_at_[hidden])
Date: 2014-12-06 09:25:23

Edward Diener <eldiener <at> tropicsoft.com> writes:

> 
> On 12/6/2014 8:19 AM, Stephen Kelly wrote:
> > Paul A. Bristow wrote:
> >>> It stands for Software of Unknown Pedigree. They classify boost as SOUP.
> >>
> >> I think this is plain wrong.
> >
> > If they have not investigated the pedigree of Boost, then of course it is
> > SOUP to them. I don't see how that could possibly be wrong.
> 
> You nicely cut off Paul's further comments.
> 
> >
> >>
> >> Boost Libraries are all
> >>
> >> 1  Peer reviewed.
> >
> > The initial submission is peer reviewed. After that there is no pre-commit
> > review requirement (I said "requirement") in Boost. The submitter/maintainer
> > then owns all decisions related to the library.
> 
> Would you like all decisions for a library made by a consensus of all 
> commenters ?
> 
> > Many boost libraries have no
> > maintainer or no active maintainer, and upkeep struggles to actually get
> > done. Am I wrong?
> 
> Yes, I believe you are wrong.
> 
> 1) A few libraries have no active maintainer.
> 2) A maintenance group of people has been formed, to which anyone may 
> join, for libraries which have no active maintainer.
> 3) Occasionally upkeep struggles to get done, but Boost is pretty 
> responsive in general IMO.
> 
> >
> >> 2...7
> >
> > I doubt any of that matters.
> 
> Matters for what ?
> 
> >
> > I found this an interesting read this week:
> >
> >   https://esrlabs.com/blog/estl-for-embedded-developers/
> 
> Interesting but "safety critical work" does not necessarily mean 
> embedded programming.
> 
> My last consulting job was for a company essentially doing "safety 
> critical work" ( they were periodically inspected/checked by the FDA ). 
> They felt that Microsoft's MFC and VC++ standard libraries were "safe" 
> but I could not convince them that using Boost libraries were "safe". 
> They were upset when they found bug reports against some Boost 
> libraries, but evidently were not at all upset when I conversely pointed 
> out bug reports against MFC and the VC++ compiler.

We use Boost for 11 years now in our products and have gained some
experience with Boost:
- almost every release something gets broken. Often I post that on the
mailing list but not many responses lately. I understand that testing many
compilers and platforms is hard especially when the c++ language is shifting
as well (e.g. circular_buffer support for move on vs2010), but perhaps Boost
can adopt a model like Ubuntu does with its LTS?
- some libraries seems to be orphaned (e.g. interval) which can be fatal if
you depend on it. I myself feel not capable of taking over some library.
- source code is available but some of them are very hard to understand.
Part of this is due to the support of broken compilers, but there is also
use of non obvious template or preprocessor magic. Also there is no
consistent code style.

This may seem a little bit harsh, but I really appreciate Boost. It has lots
of fantastic and handy libraries. I cannot comment on the safety critical
level. If your employer expects that every self written code or dependent
code can be maintained maybe above information can help you guide in the
direction to take.