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