Boost logo

Boost :

Subject: Re: [boost] The future and present of Boost
From: Raffi Enficiaud (raffi.enficiaud_at_[hidden])
Date: 2018-10-23 22:41:38

On 22.10.18 16:26, Robert Ramey via Boost wrote:
> On 10/22/18 1:53 AM, Mike Dev via Boost wrote:
>>> -----Original Message-----
>>> From: Boost <boost-bounces_at_[hidden]> On Behalf Of Robert Ramey
>>> via Boost
>>> Sent: Monday, October 22, 2018 3:33 AM
>>> But now Ranges may come as part of the standard in C++20. And then
>>> sometime after may be available when/if compiler vendors choose to
>>> implement their own version.  All in all, the committed would have been
>>> able to spend time on other stuff which only they can do.
>> They would still have had to spend the time on standardizing ranges-v3.
> My point is that complex libraries such as ranges, networking, etc.
> don't belong in the standard at all.  So in my world, the committee
> would spend zero time on these things - thus making available time on
> those things that only a standards committee can do.

I disagree with this. I am very happy to have support for database,
networking, etc in Python. And I would welcome those facilities in the
C++ standard library.

Boost has no authority over compiler vendors, while a C++
standardization has.

> That's it - the need is for high quality software components produced in
> a timely manner.  I don't believe the standards committee can accomplish
> this goal.

If you look at the people involved in

they come from industry, they have real problems to solves within C++.
And if they come up to a solution within C++, I believe this solution
would get implemented by the toolchain quite fast.

I am using boost since 2003:

Success stories:
- part of boost went to C++11 (not only MPL like stuff, but also
- compiler vendors now understand what C++ standard means (think about
Visual Studio 6). This happened before C++11
- boost showed that C++ can evolve by emerging practices (metaprog,
thread, etc)
- boost is still seen as an incubation of new practices or APIs in C++

Now the bad parts:
- no clear scope or direction: we talk about "collection" of libraries
- boost is not attractive: for instance boost.test is always compared to
catch or gtest. Boost is massive. Boost favor Boost instead of standard
- boost is not orthogonal enough to C++ standard library anymore. Boost
is not surviving this IMO.

I would make an effort to end the life of some libraries, rather than
ending the life of boost or their maintainers. Boost should accept it
successes and its failures.

- Is boost.test a success? I think it is, I am biased though. I would
love to drop support for C++03 to get rid of all the intra-library
dependencies that are polluting the usability.

- Is uBlas a success? If we get things done to accelerate, certainly.
Otherwise I will just use Eigen as before.

- Is GIL a success?

- Is boost.compute something to dig more into? I would love to see more
incentive to use things that are on the edge of C++. Is boost.mpi a player?

- is MPI still in use in HPC or do we do zeromq/spark like stuff only?

- can we go even further than the wonderful YAP?

- what usages can we pull into boost? it that math? computer vision?
database? embedded devices? network? text search algorithms? graph?


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