Boost logo

Boost :

Subject: Re: [boost] Use of boost in safety critical work
From: Edward Diener (eldiener_at_[hidden])
Date: 2014-12-06 08:46:45


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.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk