Subject: Re: [boost] Thoughts on Boost v2
From: Wouter van Ooijen (wouter_at_[hidden])
Date: 2014-05-16 13:51:54
I am working on a C++ library for small microcontrollers (the thingies
that typically have a few kilobytes of RAM). I might one day want to
submit my work to boost. I'll respond from that perspective.
> 1. Boost isn't sexy any more. As one very highly respected world
> famous engineer put it - and I won't say who, and I apologise to him
> for stealing his words without attribution:
> "Boost used to be about all the stuff you really wanted in the
> standard. Now Boost looks like all the stuff that wasn't good enough
> to get into the standard"
I think there is room for a collection of high-quality libraries that
are too specialized or too experimental to be in the standard.
> 2. I personally want as far
> away from C++ 03 as soon as is possible.
Agreed. I write my code now, for the currently available compiler(s).
For me that is the latest GCC, or maybe clang, or a vendor specific
compiler (AFAIK VS isn't a cross-compiler for bare-metal targets, so it
is not relevant, at least not for the target-dependent parts).
> 3. All the interesting new C++ 11 libraries you find around the
> internet have zero interest in trying to join Boost, with a very few
> honorable exceptions. That speaks volumes, to me at least.
I would be interesested, especially because of the review process.
> 1. Minimum required compiler feature set will be VS2014's. No use of
> Boost STL permitted where the C++ 11 STL provides a feature.
I totally agree
> 2. cmake instead of Boost.Build.
My libraries are headers-only, so I don't think this would matter much
> 3. Eliminate peer review in favour of a suite of automated libclang
> based AST analysers. Instead of persuading people to review
> libraries, persuade them to review and improve the AST analysers.
Testing is of course fine, but it can not evaluate architecture or
> 4. Mandatory cross platform per-commit CI with unit testing exceeding
> 95% coverage. We don't care what unit test library is used so long as
> it can output results Jenkins can understand.
Agreed in general, but how would you realize that for code that is
specific to a particular microcontroller?
> 5. Mandatory all green thread, memory, UB sanitisers and clean
> valgrind. All also tested per-commit.
For the targets and applications I am interested in heap, exceptions,
RTTI, and all other things that requires more than a few kB of code
(that is nearly all standard libraries!) are out of the question.
> 6. Mandatory CI testing for exception safety. I am hoping a clang
> rewriter can basically patch all exception throws and have them
> randomly throw for testing.
> 7. Per-library source distributions
> 10. BoostBook documentation using the Boost look and feel becomes
> mandatory. I've had enough with library authors thinking they can
> improve on BoostBook's output with things like using Comic Sans as
> the font or weird colour schemes throughout.
I have tried to make some sense of boostbook but I got nowhere. All
documentation about it seems to assume I know how to do thins that I
have never heard of. Note that I am mainly a Windows user.
Wouter van Ooijen
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk