Re: [boost] The future and present of Boost

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