Re: [boost] The future and present of Boost

On 10/23/18 2:11 AM, degski via Boost wrote:

On Tue, 23 Oct 2018 at 10:44, Niall Douglas via Boost wrote:

...

Interestingly, P1031 Low level file i/o and the Networking TS are not examples of those. Both require changes to the core language to work well. So I think for those two at least, they'd be before the committee no matter what.

But maybe [some of those] TS's should be permanent fixtures, sort of like associated libraries (SAL) [with added support in the language where required, to accommodate those]. The 2D Graphics should be in there as well. Writing client/server applications and/or 2D games are not things everybody does, they should not be standard libraries. But there are more of course, f.e., a GUI lib and a Crypto lib.

I'm not sure what this says - but it might be on the right track. If doing a good job for something like network TS requires some changes in the core language, then maybe the committee should focus on just those "enabling" changes. This would permit the development of network libraries untethered by the standard. So the network TS would be more of a use case, example, case study or whatever. The same could be said for 2d graphics. Perhaps some core facilities need to be added. Example might be standardizing a low level interface to SIMD graphics processors. If so, these would be suitable scope for a C++ committee. At the same time, there are lot's of different visions for a 2d graphics package. Trying to sort through this and arrive at a consensus will just end up displeasing everyone. And the above arguments apply to other stuff. But this begs the question: C++ needs a robust and complete set of high quality libraries to continue to prosper - and where are these going to come from? My argument is that organizations such as Boost are the prime candidates to fulfill this role. But in order to do so, things have to evolve. Boost is fine as far as it goes. But thinking about the future we need to address some things: a) as Nail as mentioned - an effective deployment strategy for C++ components. Given the nature of C++, binary API, tons of build options, lack of standard definition for things like visibility, runtime loaded code, etc. This is a very, very, very difficult problem in design and implementation. It's not going to be resolved by some committee with 100 people on it. Maybe, some genius will come of the woodwork and 100 people can agree - this is a big improvement. That's what I'm aiming for with "Call for Submissions - CMake for Boost". yeah, it's a crap shoot - albeit one with little downside. b) Part of this has to be finding ways to improve component reliability, ease of use, transparency/verifiability, and other measures of quality. For some reason, most programmers don't see any problem here. Personally I don't understand why - maybe it's just me. c) The above two are really about making components "composable". This a key strength/feature of C++. c) Drawing more people into the "monastic order" that is Boost. Boost is too hard to be a part of (though as far as I know there is no current celibacy requirement, but a CoC could change that). A lot of this can be addressed by addressing the above points. I see a huge vacuum crying to be filled and Boost is in an ideal position to fill it. Robert Ramey

degski