Re: [boost] Thoughts on Boost v2

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

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

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

"green thread"??

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

Yes!

> 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