Subject: Re: [boost] The future and present of Boost
From: Robert Ramey (ramey_at_[hidden])
Date: 2018-10-23 14:44:17
On 10/23/18 2:11 AM, degski via Boost wrote:
> On Tue, 23 Oct 2018 at 10:44, Niall Douglas via Boost <boost_at_[hidden]>
>> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk