Re: [boost] The future and present of 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
https://isocpp.org/std/the-committee

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 
temporaries)
- 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 
library.
- 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?

Raffi