Re: [boost] The future and present of Boost

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 don't see how ranges-v3 being in boost instead of a stand-alone repo would have made any difference for standardization, unless you assume that it would have produced a much superior design.

Hmmm - the question posed really is whether Boost adds any value at all. That is, if a boost library is equivalent to any other library on github, then what's the point of Boost. This is actually the fundamental question that Boost has to face today.

Also, considering that the "actual" ranges library depends on concepts,

I'm not sure that it necessarily depends on concepts. But even if it does, Eric implemented his own library based version of concepts. Paul Fulks was inspired by that to propose such a library for boost which failed to pass review.

I don't see how that work could have been done as part of a boost library which is commonly expected to work with a wide variety of compilers / compiler versions.

I believe that Eric's and Pauls were both portable.

...

Compared to Boost, the C++ committee is an inferior organization to design and produce quality software.

Maybe I'm getting this wrong, but I don't see Boost designing or producing any software. I see some individuals producing and maintaining great libraries (certainly in part due to feedback from other boost members) that may or may not get accepted into boost.

Right. The only software actually designed and produced by Boost are the Boost building and testing tools. BTW - how's that working out?

The one thing I can say however is that for standardizing libraries, a production quality, cross-platform implementation (which may or may not be part of boost) is much more useful than a TS that doesn't get implemented by half of the toolchains.

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

Best

Mike

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost