This was on another thread. Someone mentioned that it should be on it's own thread so here it is (slightly amended for context). For some time I've been concerned about the future of Boost as an organization. Here are the concerns I have: a) With C++11, the standards committee accepted a large portion of Boost into the standard. This left it unclear as to what the future value of Boost to C++ might be. b) The standards committee has ramped up it's efforts to include library proposals directly into the standard - thus side stepping the traditional requirement of "standardizing established practice". So this has left Boost, which helps to evolve "establish practice" outside of the development of the C++. An example of this has been the Ranges library which as been designed and developed totally within confines of the C++ standards committee. This effectively marginalizes Boost - that is, makes it less relevant and important. c) This effort by the committee is basically failing. It's creating the possibility that C++ will evolve into an ever larger and incomprehensible bag of disjoint features than it already is. It makes it much harder to learn C++. This puts C++ on a slow train to oblivion. This is not unusual with successful projects which expand their scope - as the committee has done. It's especially common for organizations run as a committee. Think large corporations: Kodak, Sears, All government organizations, universities - etc. All one has to do to see this is look at the papers list for the San Diego meeting. Also look at P0977r0. Consider that it take the committee 10 years for a proposal to evolve into something that can be delivered to users. It even takes 10 years to include something which is already in use by 100's of thousands of programmers - ASIO. Of course the C++ committee won't address the situation. Committees don't do that. They think they can remain relevant by expanding scope. and lo and behold, now they want to expand scope again to include tooling. Wake up and smell the coffee people. Learn to prioritize and limit the scope of your actions to that which only you can do. This would be better for C++. Do less - get more done! d) Boost can accept, review and deliver a new library in a year. Hence Boost has a reason to continue and exist. But Boost is also a committee - albeit a better designed one. It has to evolve as well. I think it can evolve if we continue to work on the stuff we've been successful at while at the same time experimenting with new ideas. Robert Ramey
On Sun, Oct 21, 2018, 18:51 Robert Ramey via Boost <boost@lists.boost.org> wrote: <...>
b) The standards committee has ramped up it's efforts to include library proposals directly into the standard - thus side stepping the traditional requirement of "standardizing established practice". So this has left Boost, which helps to evolve "establish practice" outside of the development of the C++. An example of this has been the Ranges library which as been designed and developed totally within confines of the C++ standards committee. This effectively marginalizes Boost - that is, makes it less relevant and important.
Ranges is a very popular library. It is still an "existing practice", but that practice is not from Boost. Here's a crazy idea - include into Boost all the prototypes that were accepted into C++. This will keep the Boost important and usefull. Users will be able to find all the upcomming libraries in one place. c) This effort by the committee is basically failing. It's creating the
possibility that C++ will evolve into an ever larger and incomprehensible bag of disjoint features than it already is. It makes it much harder to learn C++. This puts C++ on a slow train to oblivion. This is not unusual with successful projects which expand their scope - as the committee has done. It's especially common for organizations run as a committee. Think large corporations: Kodak, Sears, All government organizations, universities - etc.
I always tell people - do not put efforts into complaining, put efforts into fixing things. If you see that features do not interact well - write a paper and propose a fix. All one has to do to see this is look at the papers list for the San
Diego meeting. Also look at P0977r0. Consider that it take the committee 10 years for a proposal to evolve into something that can be delivered to users. It even takes 10 years to include something which is already in use by 100's of thousands of programmers - ASIO.
Let's be honest. 10 years of evolution made Networking TS better. Take a look at all the changes with const_buffer_1, allocators ... It's worth it. Of course the C++ committee won't address the situation. Committees
don't do that. They think they can remain relevant by expanding scope. and lo and behold, now they want to expand scope again to include tooling. Wake up and smell the coffee people. Learn to prioritize and limit the scope of your actions to that which only you can do. This would be better for C++. Do less - get more done!
Committee become bigger. More people could process more papers and deal with bigger scopes. d) Boost can accept, review and deliver a new library in a year. Hence
Boost has a reason to continue and exist. But Boost is also a committee - albeit a better designed one. It has to evolve as well. I think it can evolve if we continue to work on the stuff we've been successful at while at the same time experimenting with new ideas.
+1. I'm really interested in having all the C++2x prototypes in Boost. Looks like everyone would benefit from that. Is that a reasonable idea?
For some time I've been concerned about the future of Boost as an organization. Here are the concerns I have:
<A lot of concerns>... Thank you for sharing your concerns. Perhaps others havesimilar concerns. Maybe there is a lack of syhcnronization inthe symbiosis between Boost and C++. Well, one thingto do might be to talk about it. What are the common directionson each side? Where are things going? Is there a written agendaor a set of goals for the future? Or are the two areas simply beginningto operate asynchronously? To this day, C++ is for me personally a very powerful andexpressive languagethat can be used all the way from tinyembedded systems up to supercomputers. This kind of flexibility and portability has benefitted from the close contact betweenBoost and C++. C++ can also produce work of very high quality that adheresto standards in a measurable fashion via code metrics,safety rules, etc. This is uniquely positive and can not besaid of some other languages. I guess the best thing to do might be to figure out how andwhere C++ and Boost fit together and what both sides areconsidering for the future. With kind regards, Chris On Sunday, October 21, 2018, 8:35:22 PM GMT+2, Antony Polukhin via Boost <boost@lists.boost.org> wrote: On Sun, Oct 21, 2018, 18:51 Robert Ramey via Boost <boost@lists.boost.org> wrote: <...>
b) The standards committee has ramped up it's efforts to include library proposals directly into the standard - thus side stepping the traditional requirement of "standardizing established practice". So this has left Boost, which helps to evolve "establish practice" outside of the development of the C++. An example of this has been the Ranges library which as been designed and developed totally within confines of the C++ standards committee. This effectively marginalizes Boost - that is, makes it less relevant and important.
Ranges is a very popular library. It is still an "existing practice", but that practice is not from Boost. Here's a crazy idea - include into Boost all the prototypes that were accepted into C++. This will keep the Boost important and usefull. Users will be able to find all the upcomming libraries in one place. c) This effort by the committee is basically failing. It's creating the
possibility that C++ will evolve into an ever larger and incomprehensible bag of disjoint features than it already is. It makes it much harder to learn C++. This puts C++ on a slow train to oblivion. This is not unusual with successful projects which expand their scope - as the committee has done. It's especially common for organizations run as a committee. Think large corporations: Kodak, Sears, All government organizations, universities - etc.
I always tell people - do not put efforts into complaining, put efforts into fixing things. If you see that features do not interact well - write a paper and propose a fix. All one has to do to see this is look at the papers list for the San
Diego meeting. Also look at P0977r0. Consider that it take the committee 10 years for a proposal to evolve into something that can be delivered to users. It even takes 10 years to include something which is already in use by 100's of thousands of programmers - ASIO.
Let's be honest. 10 years of evolution made Networking TS better. Take a look at all the changes with const_buffer_1, allocators ... It's worth it. Of course the C++ committee won't address the situation. Committees
don't do that. They think they can remain relevant by expanding scope. and lo and behold, now they want to expand scope again to include tooling. Wake up and smell the coffee people. Learn to prioritize and limit the scope of your actions to that which only you can do. This would be better for C++. Do less - get more done!
Committee become bigger. More people could process more papers and deal with bigger scopes. d) Boost can accept, review and deliver a new library in a year. Hence
Boost has a reason to continue and exist. But Boost is also a committee - albeit a better designed one. It has to evolve as well. I think it can evolve if we continue to work on the stuff we've been successful at while at the same time experimenting with new ideas.
+1. I'm really interested in having all the C++2x prototypes in Boost. Looks like everyone would benefit from that. Is that a reasonable idea?
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 10/21/18 2:33 PM, Antony Polukhin via Boost wrote:
On Sun, Oct 21, 2018, 18:51 Robert Ramey via Boost <boost@lists.boost.org> wrote: <...>
Boost has a reason to continue and exist. But Boost is also a committee - albeit a better designed one. It has to evolve as well. I think it can evolve if we continue to work on the stuff we've been successful at while at the same time experimenting with new ideas.
+1.
I'm really interested in having all the C++2x prototypes in Boost. Looks like everyone would benefit from that. Is that a reasonable idea?
Boost now consists of >150 libraries, a number of them barely maintained. Who do you propose would maintain those additional projects ? I think before we can even think of an endeavour of that scale, we should fix the scalability issues we already have. Stefan -- ...ich hab' noch einen Koffer in Berlin...
On Sun, Oct 21, 2018, 23:23 Stefan Seefeld <stefan@seefeld.name> wrote:
On 10/21/18 2:33 PM, Antony Polukhin via Boost wrote:
On Sun, Oct 21, 2018, 18:51 Robert Ramey via Boost <boost@lists.boost.org> <boost@lists.boost.org> wrote: <...>
Boost has a reason to continue and exist. But Boost is also a committee - albeit a better designed one. It has to evolve as well. I think it can evolve if we continue to work on the stuff we've been successful at while at the same time experimenting with new ideas.
+1.
I'm really interested in having all the C++2x prototypes in Boost. Looks like everyone would benefit from that. Is that a reasonable idea?
Boost now consists of >150 libraries, a number of them barely maintained. Who do you propose would maintain those additional projects ?
Authors of the prototypes. They already maintain those, all they have to do is to use boost namespace and license. Maintainment of antique libraries is a separate topic. I'd rather not mix those.
On 10/21/18 11:33 AM, Antony Polukhin via Boost wrote:
On Sun, Oct 21, 2018, 18:51 Robert Ramey via Boost <boost@lists.boost.org> wrote: <...>
b) The standards committee has ramped up it's efforts to include library proposals directly into the standard - thus side stepping the traditional requirement of "standardizing established practice". So this has left Boost, which helps to evolve "establish practice" outside of the development of the C++. An example of this has been the Ranges library which as been designed and developed totally within confines of the C++ standards committee. This effectively marginalizes Boost - that is, makes it less relevant and important.
Ranges is a very popular library. It is still an "existing practice", but that practice is not from Boost.
Hmmm - where is it? I'm aware of Boost Ranges but not of any other library which implements a similar facility.
Here's a crazy idea - include into Boost all the prototypes that were accepted into C++. This will keep the Boost important and usefull. Users will be able to find all the upcomming libraries in one place.
Right, I'm sure that boost would be willing to review any such libraries when they are submitted. Robert Ramey
On Sun, 21 Oct 2018 at 22:09, Robert Ramey via Boost <boost@lists.boost.org> wrote:
Hmmm - where is it? I'm aware of Boost Ranges but not of any other library which implements a similar facility.
Eric Niebler's range-v3 library, https://github.com/ericniebler/range-v3
I'm not intimately familiar with it, but I believe it's all Boost::Range V2 and then some. Regards Rob.
On 10/21/18 3:54 PM, Robert Jones via Boost wrote:
On Sun, 21 Oct 2018 at 22:09, Robert Ramey via Boost <boost@lists.boost.org> wrote:
Hmmm - where is it? I'm aware of Boost Ranges but not of any other library which implements a similar facility.
Eric Niebler's range-v3 library, https://github.com/ericniebler/range-v3
I'm not intimately familiar with it, but I believe it's all Boost::Range V2 and then some.
Actually this is exactly what I was referring to with my point b) above. Eric is a highly respected Boost Developer (Boost.Xpressive, Boost.quickbook, and otherstuff etc.) After C++11 he got an opportunity to develop ranges under the auspices of the C++ standard committee. Many of us were disappointed that he didn't choose to do it under Boost. But of course it's his choice. 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. And Boost would have had an modern ranges library years ago. Also Boost might have had a useful library based concepts system. Only now do we have a modern replacement for mpl - this would have happened years earlier. Compared to Boost, the C++ committee is an inferior organization to design and produce quality software. It's not that they don't have smart people, it's that the C++ committee structure is setup to define and approve standards - which is not the same as designing software. Robert Ramey
Regards
Rob.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-----Original Message----- From: Boost <boost-bounces@lists.boost.org> 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. 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. Also, considering that the "actual" ranges library depends on concepts, 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.
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. 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. Best Mike
On 10/22/18 11:53 AM, Mike Dev via Boost wrote:
-----Original Message----- From: Boost <boost-bounces@lists.boost.org> 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. 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.
Existing practice is important for standardization. Generally, being part of a well-known and widely adopted project like Boost offers more opportunity for adoption to a new library than it being separate.
Also, considering that the "actual" ranges library depends on concepts, 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.
This is not quite true, in general. IIRC, when Hana was accepted, it was working only on some bleeding edge versions of gcc or clang, which were not even shipped in any distros at the time. Of course, Boost libraries strive for portability, but at the same time they are allowed to require a certain minimum C++ version. This is a per-library balance.
On 10/22/18 4:20 AM, Andrey Semashev via Boost wrote:
On 10/22/18 11:53 AM, Mike Dev via Boost wrote:
Existing practice is important for standardization. Generally, being part of a well-known and widely adopted project like Boost offers more opportunity for adoption to a new library than it being separate.
Also it allows for evolution. Standardization does not. People complain about io streams being too .... But what would be involved in getting that fixed now? No one would invest the effort to get a "fixed" version through the standards committee. Robert Ramey
-----Original Message----- From: Boost <boost-bounces@lists.boost.org> On Behalf Of Robert Ramey via Boost Sent: Monday, October 22, 2018 4:29 PM
On 10/22/18 4:20 AM, Andrey Semashev via Boost wrote:
On 10/22/18 11:53 AM, Mike Dev via Boost wrote:
Existing practice is important for standardization. Generally, being part of a well-known and widely adopted project like Boost offers more opportunity for adoption to a new library than it being separate.
Also it allows for evolution. Standardization does not. People complain about io streams being too .... But what would be involved in getting that fixed now? No one would invest the effort to get a "fixed" version through the standards committee.
I didn't say having existing practice isn't important. Actually I did quite the opposite (quoting myself):
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.
What I do say however is that 1) having such a widely used implementation doesn't necessarily reduce the amount of work the committee has to do in order to standardize: Just have a look at the things from boost that got merged into the standard (or where the committee is currently trying to merge them). 2) in times where everyone can easily publish their library on github on the one hand and projects try to actively shed or avoid their dependency on boost, having your library distributed as part of boost is certainly not the only realistic way to get lots of usage feedback. Ranges-v3 in particular became quite well-known and popular in the c++ community and I believe the main hurdle to its wide adoption was the inability of MSVC to compile it - not that it wasn't part of Boost. Again, I absolutely don't want to deny the value having a library going through boost prior to standardization. I'm just not convinced, that it would have helped the standardization process if ranges where developed as part of boost. One general problems I see with standardizing existing practice btw: A new library designed for use in production rarely gets written against the latest version of the c++ standard. Once it is written it takes quite some time until it gets adoped widely and even longer until it really becomes established practice. So at the time where you start to work on standardization, the library is designed against a language that is probably 2-4 Standard revisions older than the one in which it will gets standardized. Depending on how much the language changed in between, and how much the library has evolved in the meantime you need to spend at least some effort (and sometimes considerable effort) to bring the design in line with modern language principles (Use std::chrono duration instead of ints, using string_view, . Interesting point to think about: If you look at how standardization of communication protocols work (e.g. USB, Wifi PCI), they don't standardize established practice at all. Mike
Robert Ramey
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 10/22/18 10:13 AM, Mike Dev via Boost wrote:
What I do say however is that 1) having such a widely used implementation doesn't necessarily reduce the amount of work the committee has to do in order to standardize: Just have a look at the things from boost that got merged into the standard (or where the committee is currently trying to merge them). 2) in times where everyone can easily publish their library on github on the one hand and projects try to actively shed or avoid their dependency on boost, having your library distributed as part of boost is certainly not the only realistic way to get lots of usage feedback. Ranges-v3 in particular became quite well-known and popular in the c++ community and I believe the main hurdle to its wide adoption was the inability of MSVC to compile it - not that it wasn't part of Boost.
Again, I absolutely don't want to deny the value having a library going through boost prior to standardization. I'm just not convinced, that it would have helped the standardization process if ranges where developed as part of boost.
One general problems I see with standardizing existing practice btw:
A new library designed for use in production rarely gets written against the latest version of the c++ standard. Once it is written it takes quite some time until it gets adoped widely and even longer until it really becomes established practice.
So at the time where you start to work on standardization, the library is designed against a language that is probably 2-4 Standard revisions older than the one in which it will gets standardized. Depending on how much the language changed in between, and how much the library has evolved in the meantime you need to spend at least some effort (and sometimes considerable effort) to bring the design in line with modern language principles (Use std::chrono duration instead of ints, using string_view,
I'm arguing that the C++ standardization process is not useful for most C++ libraries. The committee can't handle it. This is pretty much a demonstrable fact as far as I'm concerned. (I realize that people will disagree with this premise). So this leaves a vacuum which organizations such a Boost can/should fill.
. Interesting point to think about: If you look at how standardization of communication protocols work (e.g. USB, Wifi PCI), they don't standardize established practice at all.
True, but their not standardizing any practice. They don't approve code or APIS etc. The leave that to someone else. They stick to the legitimate goals of standardization. I believe that one of the original goals is to "standardize existing practice" and perhaps they shouldn't do that. One thing that they do which no one else can do is specify language syntax and semantics. Expanding too far beyond this essential function can compromise the successful accomplishment of that very function. Robert Ramey
Mike
Robert Ramey
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Mon, Oct 22, 2018 at 8:27 PM Robert Ramey via Boost <boost@lists.boost.org> wrote:
On 10/22/18 10:13 AM, Mike Dev via Boost wrote:
Interesting point to think about: If you look at how standardization of communication protocols work (e.g. USB, Wifi PCI), they don't standardize established practice at all.
True, but their not standardizing any practice. They don't approve code or APIS etc. The leave that to someone else. They stick to the legitimate goals of standardization.
I believe that one of the original goals is to "standardize existing practice" and perhaps they shouldn't do that. One thing that they do which no one else can do is specify language syntax and semantics. Expanding too far beyond this essential function can compromise the successful accomplishment of that very function.
The problem is defining that "too far beyond this essential function". Is it unique_ptr? Ranges? 2D graphics? In my view, the following are good reasons/potential candidates: * Anything that is universally useful, i.e. repeated over and over in all projects with a similar implementation (e.g. containers, array, string, unique_ptr, regexp...), even if the standard one would not be perfect for all projects. * Anything that is "set in stone" or comes from other standards (e.g. math, chrono...). * Anything that requires or benefits from compiler support, i.e. anything that should be the responsibility of compiler writers, rather than third-party libraries which end up with a thousand #ifdefs (e.g. static_assert, contracts, stacktrace...) * ... Cheers, Miguel
On Tue, 23 Oct 2018 at 10:07, Miguel Ojeda via Boost <boost@lists.boost.org> wrote:
On Mon, Oct 22, 2018 at 8:27 PM Robert Ramey via Boost <boost@lists.boost.org> wrote:
On 10/22/18 10:13 AM, Mike Dev via Boost wrote:
Interesting point to think about: If you look at how standardization of communication protocols work (e.g. USB, Wifi PCI), they don't
standardize
established practice at all.
True, but their not standardizing any practice. They don't approve code or APIS etc. The leave that to someone else. They stick to the legitimate goals of standardization.
I believe that one of the original goals is to "standardize existing practice" and perhaps they shouldn't do that. One thing that they do which no one else can do is specify language syntax and semantics. Expanding too far beyond this essential function can compromise the successful accomplishment of that very function.
The problem is defining that "too far beyond this essential function". Is it unique_ptr? Ranges? 2D graphics?
Well, in respect of the 2D Graphics proposal(s), I don't get it. There is a perfectly good (C++, cross platform, mature) 2D Framework [SFML] available, which seems to have been discarded from the block. No, instead we're gonna get [probably] some poofed up C thingy, which does not even allow you to write that little 2D Game [because we need a mouse, a window, touch, sound (formats), image formats, etc etc]. I agree with RR, though, these things should not be part of C++, I don't even think the Network TS should be in the standard, it's highly specialized stuff, with heaps of pitfalls [most user posted problems on this list pertain to ASIO [and Beast (no criticism intended, it's just complicated stuff)]. degski -- *“If something cannot go on forever, it will stop" - Herbert Stein*
I agree with RR, though, these things should not be part of C++, I don't even think the Network TS should be in the standard, it's highly specialized stuff, with heaps of pitfalls [most user posted problems on this list pertain to ASIO [and Beast (no criticism intended, it's just complicated stuff)].
I think there is widespread agreement that if we had a decent and universal package management solution, most of the standard library proposals before the committee would no longer be necessary. 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. Niall
On Tue, 23 Oct 2018 at 10:44, Niall Douglas via Boost <boost@lists.boost.org> 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. degski -- *“If something cannot go on forever, it will stop" - Herbert Stein*
On 10/23/18 2:11 AM, degski via Boost wrote:
On Tue, 23 Oct 2018 at 10:44, Niall Douglas via Boost <boost@lists.boost.org> 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
On Tue, 23 Oct 2018 at 16:44, Robert Ramey via Boost <boost@lists.boost.org> wrote:
On 10/23/18 2:11 AM, degski via Boost wrote:
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].
<snip> 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.
Yes, that's exactly what I meant to say.
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.
+1 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.
With the current direction, I don't think any-one will care one single bit and will just keep on doing what they always did. io2d does not address the problem adequately, the scope is too limited and ends up being turtle-graphics-2.0. vcpkg builds SFML and the required dependencies (quite a few), all out of the box. In 20 (let's call it 2 cups of coffee) minutes after issuing 'vcpkg install SFML' you're up and running, both debug and release. The documentation and tutorials are excellent and the dev-forum is helpful, patient [there are no stupid questions, there are only in-experienced people] and reactive.
And the above arguments apply to other stuff.
Yes. degski -- *“If something cannot go on forever, it will stop" - Herbert Stein*
V V tor., 23. okt. 2018 ob 10:44 je oseba Niall Douglas via Boost < boost@lists.boost.org> napisala:
I agree with RR, though, these things should not be part of C++, I don't even think the Network TS should be in the standard, it's highly specialized stuff, with heaps of pitfalls [most user posted problems on this list pertain to ASIO [and Beast (no criticism intended, it's just complicated stuff)].
For the past 8 years I'm using ASIO (and now Beast on top of it) to crate GUIs as I already know web development and certainly don't feel like bothering with either platform specific GUI stuff or heavy weight frameworks such as Qt, WxWidgets,... Especially because web has HTML5 with all the JavaScript libraries for manipulating graphics already in place. So from my point of view Networking TS covers a big chunk of my inter process communication and GUI implementation (in both cases localhost and remote) letting me ignore Apache/NginX, PHP, C# with its ASP.NET framework... You might argue that C++ is not the best tool for web dev (and I would disagree because I really hate the devops and dependency bloat that the alternatives bring to the table) but if you ignore the "which language to use" part you can see that web and GUI world is not a small portion of programming tasks and Networking TS covers it quite well for me as the basic layer. For me being a base layer for two very different things (networking and GUI) is something that most definitely belongs into the standard - especially since C++ standard is heavily lacking in those two departments.
I think there is widespread agreement that if we had a decent and universal package management solution, most of the standard library proposals before the committee would no longer be necessary.
Universal minus at least one... Since I had to fight the NuGet packaging manager in C# today (and have fought the Java maven dependency hell quite often in the past - different libraries requiring different versions of the same library that don't play nice with one another) I somehow still believe that package management solutions are still not developed enough to be really useful on the language level (rpm and deb repositories not included [meaning that they are useful] as those start to eat away your nerves only if you are using an old/under-packaged Linux distribution or really need a custom build of a latest-latest library version) - so I'm for OS level package management (other people invest time to make the libraries play nicely together by using the same versions of one library on which other depend all the way) and don't see a universal C++ package management solution as being the thing that solves allot of library problems. 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.
+1 Now regarding the future and present of Boost I'm not a contributor/maintainer but am a long time user and before C++11 Boost libraries helped me allot. Unfortunately after C++11 release Boost started to annoy me as my compilers supported more and more of the standard implementations while Boost libraries kept their dependencies on boost versions of those same library parts. This becomes an annoyance and for me puts Boost not side by side with C++ STD library - instead it puts Boost more towards the Qt basket where you get the feeling that they want to be the be all end all framework that tries not to care about STD library as much as humanly possible (I could be wrong regarding both library bundles/frameworks but that's the feeling I got). As an outsider that probably even doesn't have enough C++ experience to contribute to Boost I see usefulness of Boost libraries such as Asio, Beast, DLL, Spirit/X3 that are not (yet) part of the standard but solve my problems - but on the other hand I dislike that DLL requires boost::filesystem (had some additional issues building Boost because of that dependency and also had to convert to std::filesystem to boost::filesystem in the code) and even submitted a patch for Beast so that I don't need to bother with boost::string_veiw and may instead use std::string_view. So from one perspective I like Boost as a location where I know I'll find quality libraries that will solve my problems but from the other that's the most that I see in current Boost as I don't have a problem using fmt [1] <https://github.com/fmtlib/fmt> library that is not in Boost (but I'm glad that it's trying to get standardized - at least in part). So to sum up: For me as a Boost library user Boost is a library hub that no longer works with C++ STD library but instead tries to compete against it as a Boost-STD library - so just another competitive framework. From my point of view Boost would become once again a C++ STD addition if it would contain libraries that are missing from the (latest?) standard and would use C++ STD parts wherever possible - C++ STD for long term stability, Boost for innovation and complementing the standard instead of trying to support N previous standards (or by being packaged differently for each C++ standard - only libraries that are missing from that standard and using boost substitutes only if they are missing in that standard version). I know that that is an awful lot of work but my guess would be that these are one of the rare options for Boost to continue to be C++ STD complementary bunch of libraries that push the standard forward instead of being just another "I work alone" blob of libraries that are splitting C++ codebases and being better-quality-C++-only-github-2 (nothing wrong with that but a different direction to pre C++11 Boost). On the other hand the only way I'd see Boost as a better place for currently proposed C++ libraries for standardization would be if C++ standard would say something like "C++ compiler is compliant to standard X only if Boost libraries X, Y, Z... are shipped with it in a working state" - and until then I prefer libraries migrating slowly from Boost into the standard. Just my two (probably useless) cents. Regards, Domen <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=icon> Virus-free. www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=webmail&utm_term=link> <#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of degski via Boost Sent: 23 October 2018 09:37 To: boost Cc: degski; Robert Ramey Subject: Re: [boost] The future and present of Boost
On Tue, 23 Oct 2018 at 10:07, Miguel Ojeda via Boost <boost@lists.boost.org> wrote:
On Mon, Oct 22, 2018 at 8:27 PM Robert Ramey via Boost <boost@lists.boost.org> wrote:
On 10/22/18 10:13 AM, Mike Dev via Boost wrote:
Interesting point to think about: If you look at how standardization of communication protocols work (e.g. USB, Wifi PCI), they don't
standardize
established practice at all.
True, but their not standardizing any practice. They don't approve code or APIS etc. The leave that to someone else. They stick to the legitimate goals of standardization.
I believe that one of the original goals is to "standardize existing practice" and perhaps they shouldn't do that. One thing that they do which no one else can do is specify language syntax and semantics. Expanding too far beyond this essential function can compromise the successful accomplishment of that very function.
The problem is defining that "too far beyond this essential function". Is it unique_ptr? Ranges? 2D graphics?
Well, in respect of the 2D Graphics proposal(s), I don't get it. There is a perfectly good (C++, cross platform, mature) 2D Framework [SFML] available, which seems to have been discarded from the block. No, instead we're gonna get [probably] some poofed up C thingy, which does not even allow you to write that little 2D Game [because we need a mouse, a window, touch, sound (formats), image formats, etc etc].
+1, but I failed to persuade the British Standards C++ group that this was precisely the sort of thing that WG21 should NOT be doing (but Boost might but hasn't). I put the highest priority for WG21 on Herb Sutters et al proposal to formally specify the language (effectively in C++ (C++++?) itself) rather than continue to fumble with language standardese that you can't automatically reason about. Boost still has a valuable role as a discoverer of language enhancements that are needed. Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830
On Tue, Oct 23, 2018 at 2:36 AM degski via Boost <boost@lists.boost.org> wrote:
<snip, question of essential C++ functions> Well, in respect of the 2D Graphics proposal(s), I don't get it. There is a perfectly good (C++, cross platform, mature) 2D Framework [SFML] available, which seems to have been discarded from the block. No, instead we're gonna get [probably] some poofed up C thingy, which does not even allow you to write that little 2D Game [because we need a mouse, a window, touch, sound (formats), image formats, etc etc]. I agree with RR, though, these things should not be part of C++, I don't even think the Network TS should be in the standard, it's highly specialized stuff, with heaps of pitfalls [most user posted problems on this list pertain to ASIO [and Beast (no criticism intended, it's just complicated stuff)].
FYI, the SDL2 backend is now merged into the ‘master’ repo (of https://github.com/cpp-io2d/P0267_RefImpl). To use it, io2d needs to be compiled with the CMake flag, -DIO2D_DEFAULT=CAIRO_SDL2 --charley
On Tue, 23 Oct 2018 at 14:26, charleyb123 <charleyb123@gmail.com> wrote:
On Tue, Oct 23, 2018 at 2:36 AM degski via Boost <boost@lists.boost.org> wrote:
<snip, question of essential C++ functions> Well, in respect of the 2D Graphics proposal(s), I don't get it. There is a perfectly good (C++, cross platform, mature) 2D Framework [SFML] available, which seems to have been discarded from the block. No, instead we're gonna get [probably] some poofed up C thingy, which does not even allow you to write that little 2D Game [because we need a mouse, a window, touch, sound (formats), image formats, etc etc]. I agree with RR, though, these things should not be part of C++, I don't even think the Network TS should be in the standard, it's highly specialized stuff, with heaps of pitfalls [most user posted problems on this list pertain to ASIO [and Beast (no criticism intended, it's just complicated stuff)].
FYI, the SDL2 backend is now merged into the ‘master’ repo (of https://github.com/cpp-io2d/P0267_RefImpl).
To use it, io2d needs to be compiled with the CMake flag, -DIO2D_DEFAULT=CAIRO_SDL2
Should I cheer or cry? FYI, I'm crying. Let's have a look a basic thing like creating a Window. I'm taking the Samples/ rocks_in_space as an example as that seems to be as close as it gets to "a simple 2D game". So we are creating a window: https://github.com/cpp-io2d/P0267_RefImpl/blob/master/P0267_RefImpl/Samples/... and https://github.com/cpp-io2d/P0267_RefImpl/blob/master/P0267_RefImpl/Samples/.... Somebody must have lost their mind, it's just raw Win32-code (and corresponding Linux x11 code (Wayland anyone? I'm on Fedora)). Now let's see how we do that in SFML: #include <SFML/Window.hpp> int main() { sf::Window window(sf::VideoMode(800, 600), "My window"); // run the program as long as the window is open while (window.isOpen()) { // check all the window's events that were triggered since the last iteration of the loop sf::Event event; while (window.pollEvent(event)) { // "close requested" event: we close the window if (event.type == sf::Event::Closed) window.close(); } } return 0; } Just to be clear we did not just do that, we created a window, an event-loop and a functioning "close that window button". This code will run as is on Windows, Linux and OSX (each in its proper native look). But, on the bright side, I'm happy that potentially P0267 will be standardized, then SFML can keep on being developed as is and can progress, introduce breaking changes if deemed useful and will not be stuck in a 3 year update cycle. degski -- *“If something cannot go on forever, it will stop" - Herbert Stein*
-----Original Message----- From: Boost <boost-bounces@lists.boost.org> On Behalf Of Robert Ramey via Boost Sent: Monday, October 22, 2018 8:27 PM
[...]
I'm arguing that the C++ standardization process is not useful for most C++ libraries.
True, but I don't see the problem. Most libraries never aspire to get standardized anyway.
The committee can't handle it. This is pretty much a demonstrable fact as far as I'm concerned. (I realize that people will disagree with this premise). So this leaves a vacuum which organizations such a Boost can/should fill.
Why does boost have to define its role in terms of its relation to the standardization process? Can't it just be a collection of well designed and well maintained open source libraries? Actually I'd like to see much more higher level libraries such as Beast in boost than the next compiler torture test (of course that would require someone writing, submitting and maintaining such libraries). Not sure if we have a violent agreement here without recognizing it.
. Interesting point to think about: If you look at how standardization of communication protocols work (e.g. USB, Wifi PCI), they don't standardize established practice at all.
True, but their not standardizing any practice. They don't approve code or APIS etc. The leave that to someone else. They stick to the legitimate goals of standardization.
I disagree. The c++ committee doesn't approve code either and the interface properties (APIs and ABIs in programming language speak) is exactly what the USB or WiFi standards define, just like the c++ standard defines interfaces. Anyway, let's keep this about boost and not the scope of the standardization committee. Mike
On 10/23/18 3:01 AM, Mike Dev via Boost wrote:
-----Original Message----- From: Boost <boost-bounces@lists.boost.org> On Behalf Of Robert Ramey via Boost Sent: Monday, October 22, 2018 8:27 PM
[...]
I'm arguing that the C++ standardization process is not useful for most C++ libraries.
True, but I don't see the problem. Most libraries never aspire to get standardized anyway.
I think there are 70 proposals to be considered in San Diego.
The committee can't handle it. This is pretty much a demonstrable fact as far as I'm concerned. (I realize that people will disagree with this premise). So this leaves a vacuum which organizations such a Boost can/should fill.
Why does boost have to define its role in terms of its relation to the standardization process?
I think that was part of original motivation for the founding of Boost. And I do see Boost as providing those things that C++ needs but shouldn't be part of the standard. So I do see role of Boost as being defined in relation to the standard.
Can't it just be a collection of well designed and well maintained open source libraries? Actually I'd like to see much more higher level libraries such as Beast in boost
Right! +1
than the next compiler torture test
(of course that would require someone writing, submitting and
maintaining such libraries).
Not sure if we have a violent agreement here without recognizing it.
I think we mostly agree. But since we're both part of Boost, we can't openly acknowledge this. Robert Ramey
On 22.10.18 16:28, Robert Ramey via Boost wrote:
On 10/22/18 4:20 AM, Andrey Semashev via Boost wrote:
On 10/22/18 11:53 AM, Mike Dev via Boost wrote:
Existing practice is important for standardization. Generally, being part of a well-known and widely adopted project like Boost offers more opportunity for adoption to a new library than it being separate.
Also it allows for evolution. Standardization does not.
There is deprecation in the standard if I am not mistaken. Removal is also up to compiler vendors as we saw not so long ago with VS2017. There is a bit a deprecation in boost, barely removal. If we want higher velocity in boost with the same energy/effort, we should reduce the mass. It is as simple as that. Raffi
On Wed, Oct 24, 2018, 00:49 Raffi Enficiaud via Boost <boost@lists.boost.org> wrote: <...>
If we want higher velocity in boost with the same energy/effort, we should reduce the mass. It is as simple as that.
+100500. For example GCC drops support of platforms that are not maintained for a while. First GCC gives a big warning in release notes, and then removes those: "Support for the powerpc*-*-*spe* target ports which have been recently unmaintained and untested in GCC has been declared obsolete in GCC 8 as announced here <https://gcc.gnu.org/ml/gcc/2018-04/msg00102.html>. Unless there is activity to revive them, the next release of GCC will have their sources permanently *removed*." I do think that this is a useful practice.
On 10/22/18 1:53 AM, Mike Dev via Boost wrote:
-----Original Message----- From: Boost <boost-bounces@lists.boost.org> 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
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@lists.boost.org> 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
On Wed, 24 Oct 2018 at 00:41, Raffi Enficiaud via Boost <boost@lists.boost.org> wrote:
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? [...]
Please, present a definition of success or failure as basis to qualify a library for removal from Boost. FYI, GIL has been abandoned, but thanks to Stefan Seefeld, who joined long lonely wolf of GIL, Christian Henning, it's maintenance has been reactivated. A couple of months ago, I joined the efforts myself, as a long time GIL user. GitHub spits around quarter of million of C++ files referring to `boost::gil`, there some larger projects that use it (I know of TuttleOFX, K-3D). I do think that Boost has become overweight and must gain some lean working mass sooner than later. GIL still directly depends on (too) many libraries: libs/bind libs/concept_check libs/config libs/core libs/crc libs/filesystem libs/function libs/integer libs/iterator libs/lambda libs/mpl libs/numeric/conversion libs/preprocessor libs/static_assert libs/test libs/type_traits (We are working on cutting the list down and I have personally planned lots of refactoring in this area - if only there was 48/7 not 24/7.) So, from my perspective, major advantage of having GIL in Boost is to keep life of GIL users and developers easier. For me personally, working on Boost.GIL rather than just GIL is also a great opportunity to hang out with super-brains of C++, listen, ask and learn from the community on ML-s, IRC or Slack. That is also a source of motivation to act in Boost areas beyond GIL. For some Boost.GIL may sound more prestigious than just GIL. Having said that, I'd like to see GIL as part of Boost, selfishly, at least for as long as I keep contributing to it. If, however, GIL is kicked out from Boost, it will not be the end of the world, neither for GIL nor for me personally as GIL user and maintainer. It would bring many challenges but also opportunities. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net
On 24.10.18 10:32, Mateusz Loskot via Boost wrote:
On Wed, 24 Oct 2018 at 00:41, Raffi Enficiaud via Boost <boost@lists.boost.org> wrote:
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? [...]
Please, present a definition of success or failure as basis to qualify a library for removal from Boost.
That is exactly what I will *not* do, this is you to define the success of the library you maintain :) You know your users and the ecosystem around the library better than anyone else.
FYI, GIL has been abandoned, but thanks to Stefan Seefeld, who joined long lonely wolf of GIL, Christian Henning, it's maintenance has been reactivated.
And I really congratulate you guys for what you achieved!
<...>
If, however, GIL is kicked out from Boost, it will not be the end of the world, neither for GIL nor for me personally as GIL user and maintainer. It would bring many challenges but also opportunities.
I never meant to put the finger on GIL as something to drop, quite the opposite in fact in the light of the recent developments. The point is: we should look at boost with fair criticism over the time and the success of the individual libraries. This success may be within boost, in the community created around that library, or anything else. Some parts are being abandoned, they are simply not needed anymore, they have their equivalent or better alternatives. Raffi
On Thu, 25 Oct 2018 at 00:43, Raffi Enficiaud via Boost <boost@lists.boost.org> wrote:
On 24.10.18 10:32, Mateusz Loskot via Boost wrote:
On Wed, 24 Oct 2018 at 00:41, Raffi Enficiaud via Boost <boost@lists.boost.org> wrote:
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. [...]
Please, present a definition of success or failure as basis to qualify a library for removal from Boost.
That is exactly what I will *not* do, this is you to define the success of the library you maintain :) You know your users and the ecosystem around the library better than anyone else. [...] The point is: we should look at boost with fair criticism over the time and the success of the individual libraries. This success may be within boost, in the community created around that library, or anything else.
Clear. I agree with your point, taken. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net
Sorry, somehow this excellent response to my post got lost in my inbox.
-----Original Message----- From: Boost <boost-bounces@lists.boost.org> On Behalf Of Robert Ramey via Boost Sent: Monday, October 22, 2018 4:26 PM
On 10/22/18 1:53 AM, Mike Dev via Boost wrote:
-----Original Message----- From: Boost <boost-bounces@lists.boost.org> 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.
+1 I completely agree for e.g. networking, graphics and similar proposals. However, I really want to have ranges in the standard, because they establish a framework of patterns and concepts around which other libraries can form. If I want to compose multiple algorithms from different libraries easily, they need to have a common format (an in case of ranges some scaffolding) and establishing this format is very difficult for an external library, even if it is widely used.
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.
Form me (as a user) there are some main properties that I automatically attribute to a boost library even if I haven't heard of it before: - I expect the quality of implementation to be generally quite good thanks to being reviewed at least once and usually having quite a few users that would surface most bugs. - I expect at least some level of support for the library for some years to come (it will not just be dropped as soon as the author starts working on a different, more interesting project). I'd certainly not make such assumptions about the latest "random github library" hyped on reddit without extensive (and time consuming) research. *That's the value the "boost label" provides for me and I guess many others.* And yes, boost has to be careful not to lose this status by dragging along libraries that are no longer properly maintained. I've seen James King in particular doing a lot of work to prevent that and I'm sure other members of boost are active in that direction too, but there is just so much work the CMT and other library maintainers can be expected to do for free. In any case, even ignoring maintenance backlog on individual libraries, this "boost label" also comes with some annoyances that - for me and some others on my team - start to outweigh the aforementioned benefits: - The build process. Every time I need to build boost with a non- standard configuration (let's say I want to enable sanitizers, build against libc++ instead of libstdc++ or cross compile to and embedded target) I'm spending hours until if find out how to make sure the (non-header-only) boost libraries get build with the proper flags using the correct toolchain and how to hook up that version of boost with the right version of my application. Almost every other modern OS library on github provides a cmake file that allows me to just add the repository into a subfolder of my project and call add_subdirectory(libs/library) and it will just adopt whatever build configuration is handed down from my Project's cmake file (Or rather the appropriate toolchain file). Don't get me wrong: b2 is certainly a wonderful build system and for "normal" builds where I can use vcpkg or the like I don't care how boost is build. - Unnecessary dependencies. All the projects I'm working on nowadays are c++14 or even 17. Why the hell does the latest version of my preferred boost library X still have a dependency on boost library Y that has been merged into the standard since c++11 or been superseded by c++11 language feature? It just adds complexity to the build process, increases compile times and sometimes leads to subtle bugs. I'm paying (sometimes little sometimes heavily) for something I don't use/need (c++98 compatibility). - Implementation complexity. This goes hand in hand with the previous point: Some boost libraries are full of #ifdefs to work around problems in compilers that are more than a decade old (NOTE I'm not talking about necessary workarounds for "recent" compilers like e.g. gcc 4.8 or even VS 2015) while simultaneously wanting to support the latest c++17 vocabulary types in their interface. Others also use ridiculously complex TMP constructs that are only necessary because they can't use post c++03 language features. I understand why those things have been necessary when the libraries where original created, and I understand that there are still users that can't use a c++11 library or a more modern compiler, but I don't know why the latest version of a boost library still has to cater to them. In my dream world, individual boost libraries would much more often make a major version bump that adopts new language facilities and drop support for older compilers instead of having a single code base that tries to simultaneous support all language standards from c++98 to c++20 across 5 different toolchain families and on 10 different platforms (I'm exaggerating of course but that's how it sometimes feels). Note that such a version bump doesn't necessarily imply a new API This would go hand in hand with deprecating and removing libraries that got merged into newer versions of the c++ standard. As always people like me tend to complain more about the things that annoy them than praise the things that help them so don't take the length of the pro/con sections as an indication of the weight of the arguments.
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.
I was talking about the library that was the reference implementation for the ranges-TS and which required an implementation of the concpets-TS only provided by gcc (I forgot the name). That was the one relevant for standardization. Ranges-v3 (the c++11 version with the library implementation of concepts) is certainly a nice library that can be used by more people but e.g. compile-times were a real bummer and it still doesn't compile on msvc. Also quite frankly: Given that it is yet another library that emulates a native language concept with insanely complex TMP machinery, I'd hate to see that library as a dependency of other header-only boost libraries whose compile-times will then remain insanely high years after real concepts have entered the standard. And I'm not sure if anyone will want to spend the time to properly maintain it once Eric moves on. Sorry for the long post Mike
Robert Ramey
Mike Dev wrote:
- Unnecessary dependencies. All the projects I'm working on nowadays are c++14 or even 17. Why the hell does the latest version of my preferred boost library X still have a dependency on boost library Y that has been merged into the standard since c++11 or been superseded by c++11 language feature? It just adds complexity to the build process, increases compile times and sometimes leads to subtle bugs. I'm paying (sometimes little sometimes heavily) for something I don't use/need (c++98 compatibility).
We've been over this a few times already. We can't simultaneously support C++03 and C++14 (without heroics) because these are ABI- and API-incompatible. If the library uses boost::function it works regardless of whether the user is on C++03 or on C++17; but if it switches to std::function automatically when available, then whenever the user's -std and the compiled Boost's -std differ, trouble ensues. We can switch to std::function unconditionally, but only if we drop C++03 (for some definition of C++03 because only the latest and greatest MSVC is ~fully C++11 compliant.)
On Wed, 24 Oct 2018 at 17:00, Peter Dimov via Boost <boost@lists.boost.org> wrote:
We can switch to std::function unconditionally, but only if we drop C++03 (for some definition of C++03 because only the latest and greatest MSVC is ~fully C++11 compliant.)
Yes, MSVC is in flux, what's the problem? We don't mind leaving you behind, but we rather not. Things are going forward, things are moving, nagging is a waste of time. What does help is filing problems, bugs ... And yes, there is only one VS version, it's the latest and the greatest, and I think that is a good thing. Old bugs will not get solved in older versions, but they will be fixed in newer versions. degski -- *“If something cannot go on forever, it will stop" - Herbert Stein*
-----Original Message----- From: Boost <boost-bounces@lists.boost.org> On Behalf Of Peter Dimov via Boost Sent: Wednesday, October 24, 2018 5:00 PM
Mike Dev wrote:
- Unnecessary dependencies. All the projects I'm working on nowadays are c++14 or even 17. Why the hell does the latest version of my preferred boost library X still have a dependency on boost library Y that has been merged into the standard since c++11 or been superseded by c++11 language feature? It just adds complexity to the build process, increases compile times and sometimes leads to subtle bugs. I'm paying (sometimes little sometimes heavily) for something I don't use/need (c++98 compatibility).
We've been over this a few times already. We can't simultaneously support C++03 and C++14 (without heroics) because these are ABI- and API-incompatible.
[...]
We can switch to std::function unconditionally, but only if we drop C++03 (for some definition of C++03 because only the latest and greatest MSVC is ~fully C++11 compliant.)
That's my point: I don't want boost libraries to invest any more effort in maintaining c++03 support (I think I made that clear in the last ml-thread about this 2-3 month ago). It either makes everything more complicated or it requires more dependencies and/or - in the worst case - leads to compile and/or run-time overhead, because an efficient c++11 language construct is emulated with some wicket macro/TMP-library solution (which are even more wicket in c++03) or we have additional conversions between boost types and std types. At the very least, it requires more test-effort, because you want to support the newer standards anyway. Before someone puts up a strawman: Of course that doesn't necessarily mean you should remove boost::X from your code if it provides other benefits (other than backwards compatibility) over std::X. And no, I'm also not suggesting to just drop a useless c++11 feature into your code just out of malice (but realistically, almost every c++03 boost library could either shed dependencies or improve the code by using c++11 features/types). I don't know what the majority of the boost user base needs and what your personal needs (as a maintainer and most likely user of your own library) are but I'm saying that, while maintaining backwards compatibility is probably important for some users, the side effects of it drive others (such as me) away from boost. It is a tradeoff and I'm certainly not so arrogant to believe that dropping backwards compat would be a net win for boost, but for me personally it would make boost more attractive again. Most other pieces of software can just bump their major version, when they think breaking backwards compat is beneficial, and the user can then either upgrade too or stick to the old version if he can't accommodate for the changes (yet). Often the old version still gets bugfix support for some time. But in boost the only way to create a v2 seems to be the introduction of a totally new library. I think that is at least one drawback of the common (non-modular) release model. Btw.: Feature/library wise, I believe the only c++11 thing missing from MSVC2015 is full constexpr support and expressions sfinae and even MSVC2013 provides most of the library and language bits. Any other conformance bugs (e.g. two-phase lookup) have to be dealt with anyway and are orthogonal to the c++03 / c++11 question. Mike
Mike Dev wrote:
We can switch to std::function unconditionally, but only if we drop C++03 (for some definition of C++03 because only the latest and greatest MSVC is ~fully C++11 compliant.)
That's my point: I don't want boost libraries to invest any more effort in maintaining c++03 support (I think I made that clear in the last ml-thread about this 2-3 month ago).
It's clear to all that everyone is held back by the inability to use C++11 things. But we can't just stop investing effort in C++03 maintenance. We have to officially drop C++03 at the Boost level, meaning, refuse to compile Boost with C++03 at all, or make it difficult, or at least make it choose an intelligent default that is never C++03. Otherwise it's easy for our (g++ 5 and clang) users to end up with Boost libraries compiled with C++03. (Of course this just kicks the can a bit further down the road - we'll then need to pick between 11 and 14 as a default for g++ 5 and clang...)
Btw.: Feature/library wise, I believe the only c++11 thing missing from MSVC2015 is full constexpr support and expressions sfinae and even MSVC2013 provides most of the library and language bits.
The point is that "C++11" is not useful as a requirement when it comes to MSVC, we need to pick a specific minimum version. 2013 is a good approximation of "C++11", I suppose.
Am 24.10.18 um 18:43 schrieb Peter Dimov via Boost:
Mike Dev wrote:
We can switch to std::function unconditionally, but only if we drop C++03 (for some definition of C++03 because only the latest and greatest > MSVC is ~fully C++11 compliant.)
That's my point: I don't want boost libraries to invest any more effort in maintaining c++03 support (I think I made that clear in the last ml-thread about this 2-3 month ago).
It's clear to all that everyone is held back by the inability to use C++11 things.
But we can't just stop investing effort in C++03 maintenance. We have to officially drop C++03 at the Boost level, meaning, refuse to compile Boost with C++03 at all, or make it difficult, or at least make it choose an intelligent default that is never C++03.
Otherwise it's easy for our (g++ 5 and clang) users to end up with Boost libraries compiled with C++03.
One thing I really do not understand is: Why should people use the newest and latest Boost version when they are stuck with an ancient compiler or code-base, which does not even support C++11? Do they really need the newest libraries from Boost? (Most of them require at least C++11 anyways.) Isn't it enough for them to stick to one Boost version that has all the needed Boost libraries and worked for a long time and be happy? OK, if they want to have the latest (security-)bugfixes, then they should get them as patches or as patch-releases of the same (old) version. My recommendation is therefore: 1. Announce that e.g. Boost 1.70 will be the last release that guarantees to compile with C++03 and that you will support it for some (longer) time by providing patch-releases (1.70.1, 1.70.2...), only including (security-related) bugfixes but no new features. (You need specific git-branches for this and they will differ over time from develop/master branch. 2. Create a new Boost 2.0 release (instead of Boost 1.71) which no longer guarantees to compile with C++03 and which guarantees to compile with at least C++11 (or better C++14). Then, for every new Boost 2.x version, you are free to remove as much C++03-only libraries or update other libraries to no longer support building with C++ standards older than the minimum required standard for Boost v2. 3. Some years later, you could create a new Boost 3.0 release which then might only guarantee to compile with at least C++17 (or C++20). And the latest Boost 2.x version will only receive (security-related) bugfixes. 4. Do the same every few years for new standards (if appropriate). You effectively would guarantee to support the latest C++ standard with the newest Boost version while gradually removing parts that no longer are required for compiling with that standard.
(Of course this just kicks the can a bit further down the road - we'll then need to pick between 11 and 14 as a default for g++ 5 and clang...)
Btw.: Feature/library wise, I believe the only c++11 thing missing from MSVC2015 is full constexpr support and expressions sfinae and even MSVC2013 provides most of the library and language bits.
The point is that "C++11" is not useful as a requirement when it comes to MSVC, we need to pick a specific minimum version. 2013 is a good approximation of "C++11", I suppose.
I think, the best would be to make a hard cut. Find a good release (e.g. Boost 1.70) you might want to support for some time for "old" compilers while meanwhile go on with newest compilers that (fully) support the latest (minimum-)standard for your Boost Major-release. If e.g. only VS2017, GCC 7 and Clang 8 would fully support that minimum-standard, then these compiler versions will be the oldest compilers supported by the newer Boost versions. I really think at one time you have to drop backward-compatibility, at least for ancient compilers and standards. Just my 2ct, Deniz Bahadir
On 10/24/18 11:12 AM, Deniz Bahadir via Boost wrote: Answering as a library maintainer. The library I maintain is C++03 compatible. This is because that was the standard in existence when it written. As new standards come into existence, sometimes a problem comes up. This is usually because of something like: the a) library depends on undefined behavior. This library could not be written in such a way to avoid this. This includes working around optimizer dropping functions in release mode. These functions are necessary but are not explicitly named. b) some undefined behavior either gets defined or becomes undefined in a different way and one or more of the tests fails. Or some new feature is implemented. The current example is that visibility is now being supported. c) I go back and make an improvement. Currently I keep the improvement consistent with C++03. it's not hard to do. d) The library is still compatible with C++03, C++11, C++14 and likely C++17. So what should I, as a maintainer be doing differently? Of course if the library were be written today, it would save a lot of time and grief to just use the latest version. Number of lines of code would probably drop by 50% or more. But the library is not being written today, so this question is not relevant. Should the library have been designed differently so it would depend less on undefined behavior? Maybe. but the library is in wide use and it was required to support wide functionality in order to pass the boost review process. With the benefit of hind sight, a couple of features which complicated the design weren't necessary and not including those would make the library simpler and easier to maintain. But there aren't very many of such features. Pretty amazing given that the library was released 15 years ago. Since all this is in the past and not that big a deal - this question is not relevant Should the library be re-written to exploit the knowledge gained over the past 15 years and make it smaller and easier to maintain? Maybe, but no one has volunteered lately. I get a lot of suggestions though. So - I just don't see any of this discussion as being at all relevant to the maintainer of an old library. Now if it were somehow mandated that libraries are prohibited from being useful with versions of C++ earlier than C++11?, that would effect me as a library maintainer. I would likely have to insert one statement which fails to compile under earlier versions to fulfill this requirement. Sooooooo - I honestly can't see any this discussion is relevant to the present and future of boost - the subject line of the thread. Robert Ramey
On 10/24/2018 2:12 PM, Deniz Bahadir via Boost wrote:
Am 24.10.18 um 18:43 schrieb Peter Dimov via Boost:
Mike Dev wrote:
We can switch to std::function unconditionally, but only if we drop C++03 (for some definition of C++03 because only the latest and greatest > MSVC is ~fully C++11 compliant.)
That's my point: I don't want boost libraries to invest any more effort in maintaining c++03 support (I think I made that clear in the last ml-thread about this 2-3 month ago).
It's clear to all that everyone is held back by the inability to use C++11 things.
But we can't just stop investing effort in C++03 maintenance. We have to officially drop C++03 at the Boost level, meaning, refuse to compile Boost with C++03 at all, or make it difficult, or at least make it choose an intelligent default that is never C++03.
Otherwise it's easy for our (g++ 5 and clang) users to end up with Boost libraries compiled with C++03.
One thing I really do not understand is:
Why should people use the newest and latest Boost version when they are stuck with an ancient compiler or code-base, which does not even support C++11? Do they really need the newest libraries from Boost? (Most of them require at least C++11 anyways.)
Isn't it enough for them to stick to one Boost version that has all the needed Boost libraries and worked for a long time and be happy? OK, if they want to have the latest (security-)bugfixes, then they should get them as patches or as patch-releases of the same (old) version.
My recommendation is therefore:
1. Announce that e.g. Boost 1.70 will be the last release that guarantees to compile with C++03 and that you will support it for some (longer) time by providing patch-releases (1.70.1, 1.70.2...), only including (security-related) bugfixes but no new features. (You need specific git-branches for this and they will differ over time from develop/master branch.
There is no such thing currently of a Boost release that is guaranteed to compile with C++03. It has been an impossibility once the first Boost library which needed C++11 on up was created. That was a long time ago.
But we can't just stop investing effort in C++03 maintenance. We have to officially drop C++03 at the Boost level, meaning, refuse to compile Boost with C++03 at all, or make it difficult, or at least make it choose an intelligent default that is never C++03.
As Beman suggested so many years ago now, it's long overdue for a separate Boost v2.x release which is shorn of the backwards compatibility and undermaintained libraries. I'd make it C++ 17 by default, too, as surveys suggest people are jumping straight from C++ 11 to C++ 17 and not stopping at C++ 14. People can keep around Boost 1.x with the existing libraries as long as people want it. Let's just break free of the ancient cruft already. And before anyone asks, it would be on each individual library maintainer to do the work to put their library into Boost 2.x. Which should be 100% cmake, incidentally. Niall
On Wed, Oct 24, 2018, 21:30 Niall Douglas via Boost <boost@lists.boost.org> wrote:
But we can't just stop investing effort in C++03 maintenance. We have to officially drop C++03 at the Boost level, meaning, refuse to compile Boost with C++03 at all, or make it difficult, or at least make it choose an intelligent default that is never C++03.
As Beman suggested so many years ago now, it's long overdue for a separate Boost v2.x release which is shorn of the backwards compatibility and undermaintained libraries.
I'd make it C++ 17 by default, too, as surveys suggest people are jumping straight from C++ 11 to C++ 17 and not stopping at C++ 14.
People can keep around Boost 1.x with the existing libraries as long as people want it. Let's just break free of the ancient cruft already.
And before anyone asks, it would be on each individual library maintainer to do the work to put their library into Boost 2.x.
I'm in. Let's do that. But let's change the namespace to avoid conflicts with Boost1, in case of some library would be included in both projects.
On Wed, Oct 24, 2018, 21:40 Antony Polukhin <antoshkka@gmail.com> wrote:
On Wed, Oct 24, 2018, 21:30 Niall Douglas via Boost <boost@lists.boost.org> wrote:
But we can't just stop investing effort in C++03 maintenance. We have to officially drop C++03 at the Boost level, meaning, refuse to compile Boost with C++03 at all, or make it difficult, or at least make it choose an intelligent default that is never C++03.
As Beman suggested so many years ago now, it's long overdue for a separate Boost v2.x release which is shorn of the backwards compatibility and undermaintained libraries.
I'd make it C++ 17 by default, too, as surveys suggest people are jumping straight from C++ 11 to C++ 17 and not stopping at C++ 14.
People can keep around Boost 1.x with the existing libraries as long as people want it. Let's just break free of the ancient cruft already.
And before anyone asks, it would be on each individual library maintainer to do the work to put their library into Boost 2.x.
I'm in. Let's do that.
I gave it another thought and now I do not like that idea. At first it seems tempting to drop a big pice of legacy libraries and leave only the most fresh ones. Let's put aside the difficulty of choosing the right library set for a moment, we have bigger problem here. The problem is that such approach is not user friendly at all. Even if we choose some optimal criteria for Boost2 libraries, there'll be always some users that wish to see one more ancient library in the new Boost. By taking the responsibility to choose the criteria we do not give users any way to affect the library set. What's more bad - we'll have to repeat the procedure each 10-30 years. And the procedure is probably require a lot of efforts from us and from users (take a look at the Python2 and Python3 story). Instead of starting a new Boost we can just deprecate the libraries more aggressively. Put a note in release notes. Say that the library X is not maintained and that if there'll be no maintainer in next 2-3 releases then the library will be removed from Boost. With this approach users can affect the decision we make. For example, users that are really interested in the library could become the new maintainers. Or they can hire a person to support 5-10 libraries for full time.
On Wed, 24 Oct 2018 at 20:31, Niall Douglas via Boost <boost@lists.boost.org> wrote:
But we can't just stop investing effort in C++03 maintenance. We have to officially drop C++03 at the Boost level, meaning, refuse to compile Boost with C++03 at all, or make it difficult, or at least make it choose an intelligent default that is never C++03.
As Beman suggested so many years ago now, it's long overdue for a separate Boost v2.x release which is shorn of the backwards compatibility and undermaintained libraries.
I'd make it C++ 17 by default, too, as surveys suggest people are jumping straight from C++ 11 to C++ 17 and not stopping at C++ 14.
+1
People can keep around Boost 1.x with the existing libraries as long as people want it. Let's just break free of the ancient cruft already.
+1
And before anyone asks, it would be on each individual library maintainer to do the work to put their library into Boost 2.x. Which should be 100% cmake, incidentally.
+1 Let's leave Boost 1.x as is, as mixture of 03, 11, 14, etc. Let's revolutionarly reserve make Fosbury's flop reserving - Boost 17.x with `-std=c++17` as minimum - Boost 20.x with `-std=c++20` as minimum ... Best regards, -- Mateusz Loskot, http://mateusz.loskot.net
On Wed, Oct 24, 2018 at 9:52 PM Mateusz Loskot via Boost <boost@lists.boost.org> wrote:
Let's leave Boost 1.x as is, as mixture of 03, 11, 14, etc. Let's revolutionarly reserve make Fosbury's flop reserving - Boost 17.x with `-std=c++17` as minimum - Boost 20.x with `-std=c++20` as minimum ...
Yes, please! In the end, users' projects only use a single revision of the language. Each library decides the minimum C++ version (like nowadays) and gets included in the relevant versioned releases. Cheers, Miguel
-----Original Message----- From: Boost <boost-bounces@lists.boost.org> On Behalf Of Peter Dimov via Boost Sent: Wednesday, October 24, 2018 6:44 PM
Mike Dev wrote:
We can switch to std::function unconditionally, but only if we drop C++03 (for some definition of C++03 because only the latest and greatest MSVC is ~fully C++11 compliant.)
That's my point: I don't want boost libraries to invest any more effort in maintaining c++03 support (I think I made that clear in the last ml-thread about this 2-3 month ago).
It's clear to all that everyone is held back by the inability to use C++11 things.
But we can't just stop investing effort in C++03 maintenance. We have to officially drop C++03 at the Boost level, meaning, refuse to compile Boost with C++03 at all, or make it difficult, or at least make it choose an intelligent default that is never C++03.
It appears different people have different opinions on whether a library can just drop c++03 support on its own. Just as different people seem to have different opinion on whether their library should drop c++03 support at all. But if I remember correctly, people on the ml agreed to announce just that (dropping c++03 support boost wide) before I went off traveling. I guess there hasn't been any new development on that front since then?
Otherwise it's easy for our (g++ 5 and clang) users to end up with Boost libraries compiled with C++03.
(Of course this just kicks the can a bit further down the road - we'll then need to pick between 11 and 14 as a default for g++ 5 and clang...)
I think - by default - all libraries should be compiled with the latest official standard a particular compiler supports (that was available at the time of its release) and tested with all supported ones. That would be 14 for g++5 and most of clang and 17 for newer compilers.
Btw.: Feature/library wise, I believe the only c++11 thing missing from MSVC2015 is full constexpr support and expressions sfinae and even MSVC2013 provides most of the library and language bits.
The point is that "C++11" is not useful as a requirement when it comes to MSVC, we need to pick a specific minimum version. 2013 is a good approximation of "C++11", I suppose.
True. Just as you might want to accommodate gcc4.8 which also isn't fully c++11 conformant. Mike
On 10/24/2018 12:43 PM, Peter Dimov via Boost wrote:
Mike Dev wrote:
We can switch to std::function unconditionally, but only if we drop C++03 (for some definition of C++03 because only the latest and greatest > MSVC is ~fully C++11 compliant.)
That's my point: I don't want boost libraries to invest any more effort in maintaining c++03 support (I think I made that clear in the last ml-thread about this 2-3 month ago).
It's clear to all that everyone is held back by the inability to use C++11 things.
But we can't just stop investing effort in C++03 maintenance. We have to officially drop C++03 at the Boost level, meaning, refuse to compile Boost with C++03 at all, or make it difficult, or at least make it choose an intelligent default that is never C++03.
Otherwise it's easy for our (g++ 5 and clang) users to end up with Boost libraries compiled with C++03.
I don't get this. Why can't library X, which needs C++11, depend on library Y, which needs C++03 but works fine if compiled with C++11. What am I missing here ? I agree, and have agreed, that Boost should spend no resources testing anything which still supports C++03. I agree, and have agreed, that end-users should be told that any library which currently support C++03 may, without prior notice, choose to support only C++11 on up in its next release. I just don't understand why a library which does support C++03 is a liability to other libraries which support C++11 ? Now if you are saying that libraries which do support C++03, but which use Boost libraries rather than their C++11 equivalents, should change to support C++11 so that their C++11 equivalents are used instead, I can understand that argument, since that was what cxxd was largely about and sought to accomplish without forcing a C++03 library to specifically change to a C++11 on up library. So I can understand the perhaps more straightforward idea of forcing a C++03 to become a C++11 library and use the C++11 equivalent library rather than the Boost library.
Edward Diener wrote:
I don't get this. Why can't library X, which needs C++11, depend on library Y, which needs C++03 but works fine if compiled with C++11. What am I missing here ?
I don't know how to answer this, and I don't know how it relates to what I was saying. What I was saying is this: the user, or someone acting on his behalf such as a package maintainer, types f.ex. b2 toolset=clang install and obtains a prebuilt Boost. Then the user types f.ex. clang++ -std=c++17 myapp.cpp -lboost_pumpkin and expects it to work. If boost_pumpkin autodetects C++11/C++14/C++17 and changes its API to match, it doesn't work. It doesn't because step 1 builds libboost_pumpkin.a with the default -std=c++03. Same with g++ 5. Not same with g++ 6 and above, whose default is C++14, but still possible if the library adapts to C++17 by using f.ex. <filesystem>.
On 10/24/2018 5:21 PM, Peter Dimov via Boost wrote:
Edward Diener wrote:
I don't get this. Why can't library X, which needs C++11, depend on library Y, which needs C++03 but works fine if compiled with C++11. What am I missing here ?
I don't know how to answer this, and I don't know how it relates to what I was saying.
What I was saying is this: the user, or someone acting on his behalf such as a package maintainer, types f.ex.
b2 toolset=clang install
and obtains a prebuilt Boost.
Then the user types f.ex.
clang++ -std=c++17 myapp.cpp -lboost_pumpkin
and expects it to work. If boost_pumpkin autodetects C++11/C++14/C++17 and changes its API to match, it doesn't work.
Is not this a user problem, irrelevant of cxxstd level ? The user is given a Boost package compiled with the default cxxstd level for clang and then attempts to use it imposing his own cxxstd level. I would expect disaster in any case except when the default cxxstd level matches what the user specifically uses, regardless of what those levels ( c++03, c++11, c++14, c++17, c++20 ) actually are. I can not imagine how this can be a Boost ( or any library ) problem as opposed to a user problem.
It doesn't because step 1 builds libboost_pumpkin.a with the default -std=c++03.
Same with g++ 5.
Not same with g++ 6 and above, whose default is C++14, but still possible if the library adapts to C++17 by using f.ex. <filesystem>.
Edward Diener wrote:
What I was saying is this: the user, or someone acting on his behalf such as a package maintainer, types f.ex.
b2 toolset=clang install
and obtains a prebuilt Boost.
Then the user types f.ex.
clang++ -std=c++17 myapp.cpp -lboost_pumpkin
and expects it to work. If boost_pumpkin autodetects C++11/C++14/C++17 and changes its API to match, it doesn't work.
Is not this a user problem, irrelevant of cxxstd level ?
It is a user problem, but note that it doesn't happen if libraries don't change their API in response to the cxxstd level. That is, libraries that assume C++03 and use the Boost components instead of their standard equivalents don't suffer from this, it all works. If we up the minimum requirement these libraries could just unconditionally transition to the std components wholesale (again without adapting to cxxstd) and it will still work (provided that we either build with an intelligent post-03 default, or quit with an error when C++03 is assumed by omission as above, thereby forcing the user to choose a preferred post-03 cxxstd level.)
On 10/24/2018 6:53 PM, Peter Dimov via Boost wrote:
Edward Diener wrote:
What I was saying is this: the user, or someone acting on his behalf such as a package maintainer, types f.ex.
b2 toolset=clang install
and obtains a prebuilt Boost.
Then the user types f.ex.
clang++ -std=c++17 myapp.cpp -lboost_pumpkin
and expects it to work. If boost_pumpkin autodetects C++11/C++14/C++17 > and changes its API to match, it doesn't work.
Is not this a user problem, irrelevant of cxxstd level ?
It is a user problem, but note that it doesn't happen if libraries don't change their API in response to the cxxstd level. That is, libraries that assume C++03 and use the Boost components instead of their standard equivalents don't suffer from this, it all works.
If we up the minimum requirement
What do you mean by the above ? Suppose you made the minimum requirement C++11, what would you expect a library to do to meet that requirement ? I think this is the gist of all the disagreements about what cxxstd Boost should support as a minimum.
these libraries could just unconditionally transition to the std components wholesale (again without adapting to cxxstd) and it will still work (provided that we either build with an intelligent post-03 default, or quit with an error when C++03 is assumed by omission as above, thereby forcing the user to choose a preferred post-03 cxxstd level.)
Edward Diener wrote:
If we up the minimum requirement
What do you mean by the above ?
We announce that Boost has a minimum requirement of such and so, and will no longer support platforms not meeting it starting with release 1.X.
Suppose you made the minimum requirement C++11, what would you expect a library to do to meet that requirement ?
The library doesn't meet the minimum requirement, the compiler does. The library may assume the minimum requirement. As an example, if our minimum requirement implies a working std::function, Boost.Test may use std::function in its interface and implementation, unconditionally and without checking cxxstd or BOOST_NO_CXX11_HDR_FUNCTIONAL or whatever else, and its maintainers can in good conscience accept pull requests making use of other C++11 features whose availability is guaranteed by the minimum requirement.
On 10/24/2018 7:49 PM, Peter Dimov via Boost wrote:
Edward Diener wrote:
If we up the minimum requirement
What do you mean by the above ?
We announce that Boost has a minimum requirement of such and so, and will no longer support platforms not meeting it starting with release 1.X.
Suppose you made the minimum requirement C++11, what would you expect a library to do to meet that requirement ?
The library doesn't meet the minimum requirement, the compiler does. The library may assume the minimum requirement.
As an example, if our minimum requirement implies a working std::function, Boost.Test may use std::function in its interface and implementation, unconditionally and without checking cxxstd or BOOST_NO_CXX11_HDR_FUNCTIONAL or whatever else, and its maintainers can in good conscience accept pull requests making use of other C++11 features whose availability is guaranteed by the minimum requirement.
Haven't we already basically agreed, going forward with Boost, that a library can use C++11 features and the C++11 Standard Library without informing end-users in advance that it is going to do so, if previously it supported C++03 ? If not, that was what I thought the previous long discussion about dropping support for C++03 was largely about. I do not think there is anything more that Boost can do to attempt to promote C++11 as the minimum standard it supports, at least at the level of each individual library. As far as Boost Test is concerned, or any other Boost library, I think it should use C++11 if it desires. If C++03 library depends on a library which has gone from C++03 to C++11 then that C++03 library is now a C++11 library as long as it maintains that dependency.
Edward Diener wrote:
Haven't we already basically agreed, going forward with Boost, that a library can use C++11 features and the C++11 Standard Library without informing end-users in advance that it is going to do so, if previously it supported C++03 ?
In theory. But theory and practice differ in practice. The theory of libraries as independent islands does not describe reality; we're a community, a team, and we tend not to do things that will create problems for other maintainers, such as unilaterally dropping C++03 support forcing all dependent libraries who still wish to support C++03 to deal with it somehow as if their maintainers had nothing better to do all day. Dropping C++03 is a collective decision that Boost will take and announce as a single entity, and then everyone can move on to C++11 with clear conscience.
On 24.10.18 22:50, Edward Diener via Boost wrote:
On 10/24/2018 12:43 PM, Peter Dimov via Boost wrote:
<...>
I don't get this. Why can't library X, which needs C++11, depend on library Y, which needs C++03 but works fine if compiled with C++11. What am I missing here ?
Technically everything is possible. It is just opposite to "practical" and redundant, and slows down development and adoption. - part of boost have redundancy with the C++ standard library. As a developer, I do not like having redundancy and I want the minimum set of dependencies, because otherwise my work gets harder. - this makes libraries artificially bigger than what they would be or need to be if I put the stdlib in the equation. Which in turn makes integration of those libraries way too difficult and lower the ratio pros vs. cons. Note that this is (a bit) orthogonal to modularity. Adding a layer of header switch/case is making the issue worse. The adoption of Boost was catalyzed by the almost standard installation of boost on their OS, because - among other things - boost was necessary in the past for doing decent C++, but this is not the case anymore. Better packaging solutions are not going to solve that neither, I still have redundancy and big fat libraries. Boost.test is a perfect example: it supports C++03 and C++11. Just compare it to the adoption of google test and catch. Those are so easy to integrate in any repository that "people" just do that. And this is not about the level of features each library brings that is the definitive game changer: simplicity of integration is a key component. I remember that the proposed solutions in this ML, if the maintainers were to drop C++03, would be to go through a formal review process of a "new" library, bringing Signal/SignalV2 as an example. This is far from ideal, especially this specific deprecation example of Signal last so many years. I remember also that some C++11 features were added to boost.test without conditional testing on the C++ standard level. This commit has received an incredible number of complains from this list, including the promoters of C++11 in this list. Those products are alive, but we constantly force them to look like the past. Any new C++ standard should give the opportunity to maintainers to update their library, immediately after the support is adopted on a minimal set of compilers, and without rebranding to boostv2 or boost.test v4. We see more and more "LTS" type of releases. Maybe we should think adopting this to give a sense of stability. Raffi
On Wed, 24 Oct 2018 at 18:44, Peter Dimov via Boost <boost@lists.boost.org> wrote:
The point is that "C++11" is not useful as a requirement when it comes to MSVC, we need to pick a specific minimum version. 2013 is a good approximation of "C++11", I suppose.
No, it is not, you'll still have lots of work-arounds [because support is patchy and buggy, and to be more blunt. it [the compiler and the STL] simply violates the standard left, right and middle], and you'll get zero response from MS reporting anything. Test stuff with the latest and the greatest and you'll have their full attention. degski -- *“If something cannot go on forever, it will stop" - Herbert Stein*
Ranges-v3 (the c++11 version with the library implementation of concepts) is certainly a nice library that can be used by more people but e.g. compile-times were a real bummer and it still doesn't compile on msvc.
Also quite frankly: Given that it is yet another library that emulates a native language concept with insanely complex TMP machinery, I'd hate to see that library as a dependency of other header-only boost libraries whose compile-times will then remain insanely high years after real concepts have entered the standard. And I'm not sure if anyone will want to spend the time to properly maintain it once Eric moves on.
You appear to be mistaken regarding a few facts. Firstly, there are now several Ranges implementations around, and I believe ALL of them compile, without hacks, on VS2017.9. Secondly the Standard C++ Foundation sponsored Eric to design and write Ranges v3 for the purpose of immediate standardisation. That makes it unique amongst all libraries entering the standard as far as I know. It was commissioned given Eric's unquestioned reputation in that space as the putative STL v2 (since rejected). Thirdly Eric is no longer the primary maintainer of Ranges v3, nor has been for at least a year or more now. He is wholly consumed with getting the thing through the committees which is extremely detailed, all-consuming work. I've sat in LEWG, it's like watching paint dry as Eric answers again and again the same questions raised again and again. Occasionally there is a nugget of gold in there, and it results in a fix avoiding a corner case problem, but for the most part Eric and Casey have thought through every design point and decision. It's just going through the motions to get the thing over to LWG. There are valid criticism of Ranges however. Firstly, even on a fully compliant compiler, they look to be much slower to compile when used in anger, and that's probably unavoidable without more powerful language abstractions. Secondly, optimisers currently are not well tuned for Ranges, and too easily give up which causes poor codegen. Thirdly, there are definitely problems at the intersection between other stuff and Ranges e.g. Eric wants lots more async and coroutines, and while I am not competent to speak on other intersections, in the area of file i/o I am very sure he is wrong on that, and indeed I dropped async file i/o entirely in P1031R1 after he couldn't give me a compelling use case to retain it. I will be starting work soon on the paper standardising support for next gen storage e.g. Samsung KV-SSD, and Ranges does not fit at all well with that either. Ranges may, or may not, have to be adjusted to cope. I have yet to discuss this with Eric, it'll be next year at earliest. So all in all, there is much work remaining, and criticism where criticism is due is valid. But criticism based on ignorance of facts is not. Niall
-----Original Message----- From: Boost <boost-bounces@lists.boost.org> On Behalf Of Niall Douglas via Boost Sent: Wednesday, October 24, 2018 8:27 PM
Ranges-v3 (the c++11 version with the library implementation of concepts) is certainly a nice library that can be used by more people but e.g. compile-times were a real bummer and it still doesn't compile on msvc.
Also quite frankly: Given that it is yet another library that emulates a native language concept with insanely complex TMP machinery, I'd hate to see that library as a dependency of other header-only boost libraries whose compile-times will then remain insanely high years after real concepts have entered the standard. And I'm not sure if anyone will want to spend the time to properly maintain it once Eric moves on.
You appear to be mistaken regarding a few facts.
Such as? As far as I can tell nothing of what you are writing relates to anything I wrote. But let's get one thing out of the way first: I didn't want to criticize the ranges library and least of all Eric. You don't have to defend him or his work (I have the greatest respect for him and the ranges-v3 library) against me. All I wanted to express is that - contrary to what Robert implied - I don't think ranges-v3 should have been developed as part of boost or even submitted to it after the design was "finished" (for some definition of finished).
Firstly, there are now several Ranges implementations around, and I believe ALL of them compile, without hacks, on VS2017.9.
2017.9 isn't released yet, but regardless of whether my use of the term "doesn't compile *yet*" was correct or not, the point was that it didn't compile on msvc for a long, long time. Regarding the multiple versions, I know of three: 1) Ranges-v3 the "original" and continuously updated c++11 implementation which did not compile on MSVC until VS2019.9 (Have you actually tested that or are you basing this on Microsoft's announcement that it "will" work?) 2) A - long since outdated and no longer maintained - fork/port of ranges-v3 that works on VS2015 (AFAIK created by Casey Carter from MS) and only compiles because it does use lots and lots of MSVC specific hacks. 3) The reference implementation for the proposal that actually used language Concepts (https://github.com/CaseyCarter/cmcstl2). That is the one I called The ""actual" ranges library", because it shows what the library is meant to Look like with full language support and without all the TMP machinery necessary to emulate concepts in c++11. That one obviously doesn't compile with anything that doesn't have concept support, which includes msvc. Do you know any other?
Secondly the Standard C++ Foundation sponsored Eric to design and write Ranges v3 for the purpose of immediate standardization. That makes it unique amongst all libraries entering the standard as far as I know. It was commissioned given Eric's unquestioned reputation in that space as the putative STL v2 (since rejected).
I know. How does that contradict anything I said?
Thirdly Eric is no longer the primary maintainer of Ranges v3, nor has been for at least a year or more now. He is wholly consumed with getting the thing through the committees which is extremely detailed, all-consuming work. I've sat in LEWG, it's like watching paint dry as Eric answers again and again the same questions raised again and again. Occasionally there is a nugget of gold in there, and it results in a fix avoiding a corner case problem, but for the most part Eric and Casey have thought through every design point and decision. It's just going through the motions to get the thing over to LWG.
Again, I know and how does that contradict anything I said? I don't think I even mentioned Eric anywhere in my mail. I was purely talking about the ranges-v3 library.
There are valid criticism of Ranges however. Firstly, even on a fully compliant compiler, they look to be much slower to compile when used in anger, and that's probably unavoidable without more powerful language abstractions.
Which is exactly what I said: ranges-v3 has to emulate a language feature (concepts) with a complex TMP solution. That is OK for an exploratory library, to get feedback on all kinds of design aspects, but in boost with it's slow deprecation cycles it would just mean that we would have been stuck with this problem for a long time. In principle it would have meant to add a library to boost that would reach it's full potential (by replacing the c++11 tmp concepts with language level concepts) only a couple of years, after it had been merge into the standard.
[.. more challenges with ranges that I'm not qualified to comment on. ..]
So all in all, there is much work remaining, and criticism where criticism is due is valid. But criticism based on ignorance of facts is not.
Again, where did I criticize anything that isn't in line with what you said? Are you maybe mixing up my post with the original one from Robert? Mike
Niall
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 10/24/18 11:26 AM, Niall Douglas via Boost wrote: <snip>
So all in all, there is much work remaining, and criticism where criticism is due is valid. But criticism based on ignorance of facts is not.
A useful exposition of wow the sausage is made. This a perfect example of why expanding the committee's scope to design of complex libraries is not a great idea. It doesn't scale. Adding mroe committees, adding more members, etc. will only make the problem worse. The only hope is to carefully limit scope of the committee to what it is actually good at. It's not the language, it's not the committee, it's not the people on the committee. It's that they have chosen to expend their efforts on the wrong thing. Robert Ramey
Niall
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Mon, Oct 22, 2018, 00:09 Robert Ramey via Boost <boost@lists.boost.org> wrote:
On 10/21/18 11:33 AM, Antony Polukhin via Boost wrote:
On Sun, Oct 21, 2018, 18:51 Robert Ramey via Boost
<...>
Right, I'm sure that boost would be willing to review any such libraries when they are submitted.
I'm proposing to relax the review requirements for those libraries. Include them even if the Boost feedback was "need more work". Simplify the review process. We should give users and library authors a simple way to meet and interact. Boost is a perfect platform for establishing existing practice and ensuring library quality. Let's not loose it because of the exhausting review process that requires a lot of time and scares of some of the authors. If the library accepted into C++ or Library Fundamentals - then it was already reviewed. Another idea: how about dropping the "review manager" requirement? Allow library author to manage the review and require a separate manager only if the votes for library inclusion are doubtful or there's less than N votes.
On Mon, 22 Oct 2018 at 10:16, Antony Polukhin via Boost <boost@lists.boost.org> wrote:
Another idea: how about dropping the "review manager" requirement? Allow library author to manage the review and require a separate manager only if the votes for library inclusion are doubtful or there's less than N votes.
+1 IOW, let's replace Review Manager with Review Arbiter, only called if necessary. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net
On 10/22/18 11:14 AM, Antony Polukhin via Boost wrote:
Another idea: how about dropping the "review manager" requirement? Allow library author to manage the review and require a separate manager only if the votes for library inclusion are doubtful or there's less than N votes.
Review manager's responsibility is not to merely count the votes. The person has to be a reasonable expert in the field, who should see pros and cons of the library, weigh the points raised in the reviews and make an informed decision (which might be against the votes, in principle). And, obviously, the library author, despite any intended honesty, will be biased in making such a decision.
On 10/22/18 1:14 AM, Antony Polukhin via Boost wrote:
On Mon, Oct 22, 2018, 00:09 Robert Ramey via Boost <boost@lists.boost.org> wrote:
On 10/21/18 11:33 AM, Antony Polukhin via Boost wrote:
On Sun, Oct 21, 2018, 18:51 Robert Ramey via Boost
<...>
Right, I'm sure that boost would be willing to review any such libraries when they are submitted.
I'm proposing to relax the review requirements for those libraries. Include them even if the Boost feedback was "need more work". Simplify the review process.
We already do this. Some libraries have been "accepted" with conditions which have entailed a long time - some times years to meet. The lastest instance is the safe numerics library. This was accepted. But the review revealed problems which took 18 months to fix (and still not quite done).
We should give users and library authors a simple way to meet and interact. Boost is a perfect platform for establishing existing practice and ensuring library quality.
I think we have this and I think it's the key feature of boost. Requirements (testing, docs, etc.) a review processes. No other option provides this.
Let's not loose it because of the exhausting review process that requires a lot of time and scares of some of the authors. If the library accepted into C++ or Library Fundamentals - then it was already reviewed.
Maybe the library interface, but certainly not the rest of it: code, docs, tests, etc. BTW, what would be the point of implementing a library accepted into C++ - Won't that be implemented by the vendor anyway?
Another idea: how about dropping the "review manager" requirement? Allow library author to manage the review and require a separate manager only if the votes for library inclusion are doubtful or there's less than N votes.
If an author finds boost requirements to onerous, he should just upload it to github. He doesn't have to follow Boost at all. He can even get it reviewed by reddit/cpp/review - https://www.reddit.com/r/cpp_review/ . No need for Boost at all if it's to much of a problem. Personally, I think the requirements to be accepted into boost too loose and we should raise them to an even higher standard. Robert Ramey
On 22.10.18 10:14, Antony Polukhin via Boost wrote:
On Mon, Oct 22, 2018, 00:09 Robert Ramey via Boost <boost@lists.boost.org> wrote:
On 10/21/18 11:33 AM, Antony Polukhin via Boost wrote:
On Sun, Oct 21, 2018, 18:51 Robert Ramey via Boost
<...>
Right, I'm sure that boost would be willing to review any such libraries when they are submitted.
I'm proposing to relax the review requirements for those libraries. Include them even if the Boost feedback was "need more work". Simplify the review process.
We should give users and library authors a simple way to meet and interact. Boost is a perfect platform for establishing existing practice and ensuring library quality. Let's not loose it because of the exhausting review process that requires a lot of time and scares of some of the authors. If the library accepted into C++ or Library Fundamentals - then it was already reviewed.
I agree. Especially we have more opportunities to mature things "today" than back in 2003: - git allowing forking, creation or PR - platforms like Github that offers issues tracking, doc, conversation, review all in one place All those things existed before to some extent, but now collaboration is easier and faster. R.
On 10/22/18 01:14, Antony Polukhin via Boost wrote:
Another idea: how about dropping the "review manager" requirement? Allow library author to manage the review and require a separate manager only if the votes for library inclusion are doubtful or there's less than N votes.
The review process is not a democracy vote. The review manager is *the* decision maker to include or not include a library. The review manager position is critical to the entire process. -- Michael Caisse Ciere Consulting ciere.com
All one has to do to see this is look at the papers list for the San Diego meeting. Also look at P0977r0. Consider that it take the committee 10 years for a proposal to evolve into something that can be delivered to users. It even takes 10 years to include something which is already in use by 100's of thousands of programmers - ASIO.
In fairness, this is because its champions refuse to split ASIO into the bit everybody agrees with - the synchronous API - from the bit which is dependent on stuff not finished i.e. the asynchronous API. If its champions were willing to fold deadlines/timeouts into the synchronous API and leave off the asynchronous API for C++ 23, they could ship, now, for C++ 20. So in the end the lack of any Networking in C++ 20 is 100% down to its sponsors and champions, not the committee who have repeated pleaded - even formally by Direction itself (P0939) - to get Networking into C++ 20.
Of course the C++ committee won't address the situation. Committees don't do that. They think they can remain relevant by expanding scope. and lo and behold, now they want to expand scope again to include tooling. Wake up and smell the coffee people. Learn to prioritize and limit the scope of your actions to that which only you can do. This would be better for C++. Do less - get more done!
You may not yet be aware that WG21 is launching lots of new SGs, and spitting LEWG into pre-LEWG and LEWG all as part of handling better the increased workload. Its scope has markedly increased from even a few weeks ago. And now to Antony ... On 21/10/2018 19:33, Antony Polukhin via Boost wrote:
Ranges is a very popular library. It is still an "existing practice", but that practice is not from Boost.
Here's a crazy idea - include into Boost all the prototypes that were accepted into C++. This will keep the Boost important and usefull. Users will be able to find all the upcomming libraries in one place.
Eric Niebler is on record saying the primary reason he didn't submit Ranges v3 to Boost was the documentation requirement, which was onerous. My main blocker for finishing Outcome is having to rewrite the documentation yet again. Everything else was finished six months ago. If Boost could start leveraging its ample cash reserves to solve the documentation problem, that would solve the problem. So, specifically speaking, each year the Boost SC allocates a fixed chunk of cash for documenting some reference library implementation of an approved upcoming C++ standard library. A popularity vote is held by Boost on which of the choices should win this. The winner has professional technical writers hired to write the documentation. The finished result appears on boost-dev for a mini-review. If approved, it enters Boost. Speaking personally, I have something like five reference library implementations before standards now. All lack documentation, and I have no intent to write any beyond what is there now. I personally wouldn't mind investing the work to get some or all of those into Boost, BAR writing the documentation. I can't speak for Eric or Casey, but I can see that for them the additional work to enter Boost - bar the documentation - is fairly insignificant compared to what has already been invested for standards. They may well be willing. Ultimately though somebody needs to create consensus to do this here on boost-dev, ask the Boost SC for the funding, and then run the annual competition. Boost has the money, there are lots of Boost-quality standards reference libraries to choose from. Just somebody needs to do the admin to make it happen.
Another idea: how about dropping the "review manager" requirement? Allow library author to manage the review and require a separate manager only if the votes for library inclusion are doubtful or there's less than N votes.
I'd strongly oppose this, except where a review manager can be substituted by WG21 having formally decided to standardise a library. I appreciate lack of review managers gates the number of new libraries in Boost [1]. But, to be blunt, Boost is about *popular* libraries. If a library can't find a review manager, not enough enough of an itch is there to be scratched. That's the whole point of having review managers, to filter out too-niche libraries. [1] I really, really, really, really wish Boost would expunge the undermaintained libraries already. They waste productivity for so many people out there who think they're using a Boost quality library, when they're not, and get badly burned for it. Niall
On 10/22/18 1:49 AM, Niall Douglas via Boost wrote:
All one has to do to see this is look at the papers list for the San Diego meeting. Also look at P0977r0. Consider that it take the committee 10 years for a proposal to evolve into something that can be delivered to users. It even takes 10 years to include something which is already in use by 100's of thousands of programmers - ASIO.
In fairness, this is because its champions refuse to split ASIO into the bit everybody agrees with - the synchronous API - from the bit which is dependent on stuff not finished i.e. the asynchronous API.
If its champions were willing to fold deadlines/timeouts into the synchronous API and leave off the asynchronous API for C++ 23, they could ship, now, for C++ 20. So in the end the lack of any Networking in C++ 20 is 100% down to its sponsors and champions, not the committee who have repeated pleaded - even formally by Direction itself (P0939) - to get Networking into C++ 20.
This is what I'm talking about. Design by the standards committee is not a good use of the committees time and resources. If they insist on mandating libraries (itself a bad idea), the should just stick to evaluation of existing libraries.
Of course the C++ committee won't address the situation. Committees don't do that. They think they can remain relevant by expanding scope. and lo and behold, now they want to expand scope again to include tooling. Wake up and smell the coffee people. Learn to prioritize and limit the scope of your actions to that which only you can do. This would be better for C++. Do less - get more done!
You may not yet be aware that WG21 is launching lots of new SGs, and spitting LEWG into pre-LEWG and LEWG all as part of handling better the increased workload. Its scope has markedly increased from even a few weeks ago.
LOL - Right. This is what all organizations do when they are faced with the failure to accomplish their stated objectives. They add more objectives! The try to become too big to fail. Sears heads down the toilet and they ... buy Lands End. It's an all two familiar patter. What they need to do is cut scope back to something they can actually do a good job on.
And now to Antony ... On 21/10/2018 19:33, Antony Polukhin via Boost wrote:
Ranges is a very popular library. It is still an "existing practice", but that practice is not from Boost.
Here's a crazy idea - include into Boost all the prototypes that were accepted into C++. This will keep the Boost important and usefull. Users will be able to find all the upcomming libraries in one place.
Eric Niebler is on record saying the primary reason he didn't submit Ranges v3 to Boost was the documentation requirement, which was onerous.
So he couldn't meet the requirements of Boost so it went to the standard. Boost standards exceed those imposed by the committee! This is why Boost is more successful than the committee in promoting development of quality libraries.
My main blocker for finishing Outcome is having to rewrite the documentation yet again. Everything else was finished six months ago.
I've had a lot to say about documentation. My advice to you and others with this complaint is that you must be doing it wrong. If you're waiting until the end of the process to add documentation, you're missing out on getting a better design. Here is what I have to say on the subject: https://www.youtube.com/watch?v=YxmdCxX9dMk Just follow these instructions and you'll find documentation a joy to write and the quality of your libraries will be much improved. You'll also find the review process, be it at C++ committee or at Boost, much, much less onerous - almost a pleasure. And you'll find that the review itself will be much, much more helpful than you've found in the past.
If Boost could start leveraging its ample cash reserves to solve the documentation problem, that would solve the problem.
Hmmm - I'm not seeing how spending more money would change peoples way of going about it. It's not a technical problem.
So, specifically speaking, each year the Boost SC allocates a fixed chunk of cash for documenting some reference library implementation of an approved upcoming C++ standard library. A popularity vote is held by Boost on which of the choices should win this. The winner has professional technical writers hired to write the documentation. The finished result appears on boost-dev for a mini-review. If approved, it enters Boost.
It would be free and alot easier if people just spent a little time learning how to do it properly.
Another idea: how about dropping the "review manager" requirement? Allow library author to manage the review and require a separate manager only if the votes for library inclusion are doubtful or there's less than N votes.
I'd strongly oppose this, except where a review manager can be substituted by WG21 having formally decided to standardise a library.
Hmm - once a library is standardized, I believe that vendors are required to provide it so that their compiler is considered "conforming". BTW - how a compile with easily demonstrable bugs are now considered "conforming" is beyond me.
I appreciate lack of review managers gates the number of new libraries in Boost [1].
But, to be blunt, Boost is about *popular* libraries. If a library can't find a review manager, not enough enough of an itch is there to be scratched. That's the whole point of having review managers, to filter out too-niche libraries.
Personally, I've got no problem with "too niche" libraries. You're right they might have to scrounge around for a review manager. But as you note this is not a big problem.
[1] I really, really, really, really wish Boost would expunge the undermaintained libraries already. They waste productivity for so many people out there who think they're using a Boost quality library, when they're not, and get badly burned for it.
If Boost were able to support modular deployment, this problem would go away. That is, if a library weren't being used, no one would download it and it wouldn't matter. Robert Ramey
On Mon, Oct 22, 2018 at 4:49 AM Niall Douglas via Boost < boost@lists.boost.org> wrote:
I appreciate lack of review managers gates the number of new libraries in Boost [1].
But, to be blunt, Boost is about *popular* libraries. If a library can't find a review manager, not enough enough of an itch is there to be scratched. That's the whole point of having review managers, to filter out too-niche libraries.
[1] I really, really, really, really wish Boost would expunge the undermaintained libraries already. They waste productivity for so many people out there who think they're using a Boost quality library, when they're not, and get badly burned for it.
Niall
Could you be more specific? Which libraries need attention? If you want to reply directly I can work with the CMT to assess. Issues like this need to be brought up on the mailing list if folks thing something is being neglected. We do have some procedures for dealing with this. I know we need to find new homes for libraries that Beman was maintaining. We're removing Boost.Signals(v1) in 1.69.0. It was deprecated for.. a long time. (too long...) - Jim
[1] I really, really, really, really wish Boost would expunge the undermaintained libraries already. They waste productivity for so many people out there who think they're using a Boost quality library, when they're not, and get badly burned for it.
Could you be more specific? Which libraries need attention?
Oh I've been quite specific in the past. I've given up trying.
If you want to reply directly I can work with the CMT to assess. Issues like this need to be brought up on the mailing list if folks thing something is being neglected.
A long time ago I made a list of Boost libraries ordered by the number of open, unresolved issues weighted by their age squared. The library which comes top of that list nobody would say isn't maintained, but the next few are very likely candidates for expunge. They don't have a maintainer, have long standing severe bugs which ruin productivity for their users, and worst of all, *do not advertise their low quality* in their documentation. They are also not core libraries, so removing them won't break other Boost libraries. Me personally, for each library without a maintainer I'd print a box at the top of every page in their documentation showing how many open bugs there are, and the average age of that open bug. Plus a wee note asking for somebody to step up to take over as maintainer. That means Boost stops lying to its user base wrt to its patchy quality.
We do have some procedures for dealing with this. I know we need to find new homes for libraries that Beman was maintaining.
Somebody, not me, ought to make a Boost.Filesystem v4 written using LLFIO. It would be an enormous improvement on STL <filesystem>, and would be the basis for the future reform of STL <filesystem>, which has a lot of problems.
We're removing Boost.Signals(v1) in 1.69.0. It was deprecated for.. a long time. (too long...)
My personal biggest bugbear is Boost.Iostreams. It should have been deprecated years ago. And I keep answering questions by perplexed users on StackOverflow who have sunk significant costs into adopting that library, and then find out to their horrible surprise that their work must be completely discarded and they have to start again with a non-fundamentally-broken alternative. Thankfully, we are on course to be able to offer in the C++ standard library a somewhat complete alternative to Boost.Iostreams by C++ 23, god willing. Niall
I agree with Niall. I have been using boost for many years and would love that feature to be part of the documentation. A library that is not maintained puts a bad reputation on boost. And while I used to think that being part of boost would be synonymous with high quality and good performance, this is not always the case anymore. Boost still contains a number of very good quality libraries, but the age is beginning to show. On Tue, Oct 23, 2018 at 10:29 AM Niall Douglas via Boost <boost@lists.boost.org> wrote:
[1] I really, really, really, really wish Boost would expunge the undermaintained libraries already. They waste productivity for so many people out there who think they're using a Boost quality library, when they're not, and get badly burned for it.
Could you be more specific? Which libraries need attention?
Oh I've been quite specific in the past. I've given up trying.
If you want to reply directly I can work with the CMT to assess. Issues like this need to be brought up on the mailing list if folks thing something is being neglected.
A long time ago I made a list of Boost libraries ordered by the number of open, unresolved issues weighted by their age squared. The library which comes top of that list nobody would say isn't maintained, but the next few are very likely candidates for expunge. They don't have a maintainer, have long standing severe bugs which ruin productivity for their users, and worst of all, *do not advertise their low quality* in their documentation. They are also not core libraries, so removing them won't break other Boost libraries.
Me personally, for each library without a maintainer I'd print a box at the top of every page in their documentation showing how many open bugs there are, and the average age of that open bug. Plus a wee note asking for somebody to step up to take over as maintainer. That means Boost stops lying to its user base wrt to its patchy quality.
We do have some procedures for dealing with this. I know we need to find new homes for libraries that Beman was maintaining.
Somebody, not me, ought to make a Boost.Filesystem v4 written using LLFIO. It would be an enormous improvement on STL <filesystem>, and would be the basis for the future reform of STL <filesystem>, which has a lot of problems.
We're removing Boost.Signals(v1) in 1.69.0. It was deprecated for.. a long time. (too long...)
My personal biggest bugbear is Boost.Iostreams. It should have been deprecated years ago. And I keep answering questions by perplexed users on StackOverflow who have sunk significant costs into adopting that library, and then find out to their horrible surprise that their work must be completely discarded and they have to start again with a non-fundamentally-broken alternative.
Thankfully, we are on course to be able to offer in the C++ standard library a somewhat complete alternative to Boost.Iostreams by C++ 23, god willing.
Niall
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
participants (23)
-
Andrey Semashev -
Antony Polukhin -
charleyb123 -
Christopher Kormanyos -
degski -
Deniz Bahadir -
Domen Vrankar -
Edward Diener -
James E. King III -
Mateusz Loskot -
Michael Caisse -
Miguel Ojeda -
Mike Dev -
mike.dev＠gmx.de
-
Niall Douglas -
Paul A. Bristow -
Peter Dimov -
Peter Dimov -
Peter Koch Larsen -
Raffi Enficiaud -
Robert Jones -
Robert Ramey -
Stefan Seefeld