[parameter] Go C++11 and above only, or keep C++03 support?
Hi, everyone. The end of section 3.2.1 of the current Boost.Parameter home page tutorial notes "that because of the forwarding problem, parameter::parameters::operator() can't accept non-const rvalues". I've submitted a PR to the develop branch on GitHub that would grant Boost.Parameter the ability to support perfect forwarding and eliminate this issue. However, the PR uses rvalue references (in parameter::keyword, parameter::parameters, and the code generation macros) and variadic templates (in parameter::parameters and the code generation macros). With the exception of BOOST_PARAMETER_TEMPLATE_KEYWORD, the PR would make Boost.Parameter a C++11 library. As a result--based on < http://pdimov.github.io/boostdep-report/develop/parameter.html#reverse-dependencies>--the following Boost libraries known to use Boost.Parameter would also become C++11: Boost.Accumulators Boost.Convert Boost.Graph Boost.Heap Boost.Log Boost.MetaStateMachine or Boost.MSM Boost.Parameter_Python Boost.Signals2 I'd like to hear from everyone else, especially the maintainers and users of these libraries, if it's okay for Boost.Parameter to go C++11 and above only or if C++03 support is still necessary. Cromwell D. Enage
On Fri, Nov 2, 2018 at 9:17 PM Cromwell Enage via Boost < boost@lists.boost.org> wrote:
The end of section 3.2.1 of the current Boost.Parameter home page tutorial notes "that because of the forwarding problem, parameter::parameters::operator() can't accept non-const rvalues".
This seems like the kind of feature that could be optional and only turned on when possible. Why not go that route? -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net
Hi, Rene. I've gone that route before, and I can do so again, although currently I'm running into an unexpected difficulty getting the legacy portions of the code generation macros to cooperate with a couple of corner cases. I removed C++03 support with the understanding that the rest of Boost would drop C++03 support starting with the upcoming release. Please let me know if I'm mistaken. Cromwell D. Enage
On Fri, Nov 2, 2018 at 9:48 PM Cromwell Enage via Boost < boost@lists.boost.org> wrote:
I've gone that route before, and I can do so again, although currently I'm running into an unexpected difficulty getting the legacy portions of the code generation macros to cooperate with a couple of corner cases. I removed C++03 support with the understanding that the rest of Boost would drop C++03 support starting with the upcoming release. Please let me know if I'm mistaken.
I'm not objecting.. I was only curious if there was some technical reason. -- -- Rene Rivera -- Grafik - Don't Assume Anything -- Robot Dreams - http://robot-dreams.net
On Fri, Nov 2, 2018 at 10:48 PM Cromwell Enage wrote:
I removed C++03 support with the understanding that the rest of Boost would drop C++03 support starting with the upcoming release. Please let me know if I'm mistaken.
It has not been announced or finalized yet, and as such, is not the case currently for the upcoming Boost 1.69 release. Glen
On 11/3/2018 12:04 AM, Glen Fernandes via Boost wrote:
On Fri, Nov 2, 2018 at 10:48 PM Cromwell Enage wrote:
I removed C++03 support with the understanding that the rest of Boost would drop C++03 support starting with the upcoming release. Please let me know if I'm mistaken.
It has not been announced or finalized yet, and as such, is not the case currently for the upcoming Boost 1.69 release.
The changes mentioned in Parameter will not be in the 1.69 release, but are planned for the 1.70 release. We have also discussed extensively that Boost will be dropping support for C++03 and what this means.
Glen
Edward Diener wrote:
We have also discussed extensively that Boost will be dropping support for C++03 and what this means.
We did discuss it, but we haven't decided anything yet. And if/when we do, we'll need to announce it at least one release in advance. (We still have time, in principle, for the decision and for the announcement that 1.69 will be the last C++03 release. I doubt that we'll reach consensus so quickly though.)
On Sat, 3 Nov 2018 at 06:57, Peter Dimov via Boost <boost@lists.boost.org> wrote:
We did discuss it, but we haven't decided anything yet.
The writing is on the wall, the inevitable will need to be done at some point. Here [with OP's question] we have a perfect example why this will be happening. My advice: Take the blue pill and cut the green wire coming of the battery going to that pipe-like structure next to the ticking clock [before it goes kaboom]. degski -- *“If something cannot go on forever, it will stop" - Herbert Stein*
On 11/3/18 5:17 AM, Cromwell Enage via Boost wrote:
Hi, everyone.
The end of section 3.2.1 of the current Boost.Parameter home page tutorial notes "that because of the forwarding problem, parameter::parameters::operator() can't accept non-const rvalues". I've submitted a PR to the develop branch on GitHub that would grant Boost.Parameter the ability to support perfect forwarding and eliminate this issue. However, the PR uses rvalue references (in parameter::keyword, parameter::parameters, and the code generation macros) and variadic templates (in parameter::parameters and the code generation macros). With the exception of BOOST_PARAMETER_TEMPLATE_KEYWORD, the PR would make Boost.Parameter a C++11 library. As a result--based on < http://pdimov.github.io/boostdep-report/develop/parameter.html#reverse-dependencies>--the following Boost libraries known to use Boost.Parameter would also become C++11:
Boost.Log
I'd like to hear from everyone else, especially the maintainers and users of these libraries, if it's okay for Boost.Parameter to go C++11 and above only or if C++03 support is still necessary.
I would prefer to keep backward compatibility with C++03, if possible. Is it possible to use Boost.Move or conditionally enable perfect forwarding on C++11 and retain the old code for C++03?
Hello, Andrey. It's possible to retain the old code for C++03 compilers. Which ones do your library users have? Cromwell D. Enage
On Sat, Nov 3, 2018 at 7:48 AM Cromwell Enage wrote:
It's possible to retain the old code for C++03 compilers. Which ones do your library users have?
For now, until all the library authors in question provide you with some list of C++ implementations that they want to support, you can ensure the current tested C++ implementations in the Develop and Master regression matrix, as well as any in the Travis and Appveyor, continue to pass if they did before. But since this pull request is targeting Boost 1.70, it looks like there is no rush anyway. After the ISO C++ committee meeting, I will be happy to help (with code or reviews) if you find supporting C++03 difficult in some way. Glen
On 11/3/18 2:47 PM, Cromwell Enage via Boost wrote:
Hello, Andrey.
It's possible to retain the old code for C++03 compilers. Which ones do your library users have?
I don't have this data. Boost.Log is documented to support gcc since 4.5 and MSVC since 8.0 SP1. It might be ok to raise the minimum requirement a bit, if it makes it easier to support in Boost.Parameter and other lower level libraries, but switching sraight to C++11 might be big deal for users. I'm not adamantly against it, not to the point I would rewrite Boost.Log just to stay C++03 compatible. But it would seem that the C++11 requirement is not that necessary in Boost.Parameter either - you can just keep the existing code in C++03 mode it it'll work as before.
On Sat, 3 Nov 2018 at 14:41, Andrey Semashev via Boost < boost@lists.boost.org> wrote:
On 11/3/18 2:47 PM, Cromwell Enage via Boost wrote:
Hello, Andrey.
It's possible to retain the old code for C++03 compilers. Which ones do your library users have?
I don't have this data. Boost.Log is documented to support gcc since 4.5 and MSVC since 8.0 SP1. It might be ok to raise the minimum requirement a bit, if it makes it easier to support in Boost.Parameter and other lower level libraries, but switching sraight to C++11 might be big deal for users.
The following question has been asked many times by many posters and there never is an answer: "Those users who want to stick to the old ways of doing things and like to use unsafe compilers [Meltdown, Spectre come to mind], why can't they just use old versions of Boost?" Why does the latest version of Boost need to work with the oldest (limping) compiler in existence. If you are [as a user] sticking to C++98 [forget C++03, that's just cosmetics] you are seriously hampering yourself. Also as Edward points out, compiling things with a later std does not imply that "the" user [or Boost] code needs to change [at least in the case of C++11, there are very few changes that are required]. There was, as far as I read it, considerable support to at least move to C++11, which is already 2 standards behind the current standard [and is by now fully supported on the main platforms]. Whatever is documented is not relevant, if the docs are out of date, they have to be updated. If every time this kind of question pops up, the answer is, "let's keep backward compatibility", then when are we gonna move to a newer standard? Or to put it differently, a direct question to you Andrey, at which point in time [which new std, 20, 23, 26, 29, 32???] do you think it will be opportune to move to C++11 and break with C++98 [because doing nothing will always be easier]?
I'm not adamantly against it, not to the point I would rewrite Boost.Log just to stay C++03 compatible. But it would seem that the C++11 requirement is not that necessary in Boost.Parameter either - you can just keep the existing code in C++03 mode it it'll work as before.
I guess, it's always possible to write more code [that's what you ask all maintainers to do] and work around the C++11 specificities? Why do we even get/need new standards, if one can just as well keep writing code the old way, it's absolutely useless [those new standards], the old stuff works. There does not need to be a new Boost release either, it worked so far, and we can write code to work around the bugs [that's what (some) people seem to do] or just depend on known UB [as long as you don't change the compiler, it will keep working]. degski -- *“If something cannot go on forever, it will stop" - Herbert Stein*
On 11/3/18 4:21 PM, degski wrote:
On Sat, 3 Nov 2018 at 14:41, Andrey Semashev via Boost <boost@lists.boost.org <mailto:boost@lists.boost.org>> wrote:
On 11/3/18 2:47 PM, Cromwell Enage via Boost wrote: > Hello, Andrey. > > It's possible to retain the old code for C++03 compilers. Which ones do > your library users have?
I don't have this data. Boost.Log is documented to support gcc since 4.5 and MSVC since 8.0 SP1. It might be ok to raise the minimum requirement a bit, if it makes it easier to support in Boost.Parameter and other lower level libraries, but switching sraight to C++11 might be big deal for users.
The following question has been asked many times by many posters and there never is an answer: "Those users who want to stick to the old ways of doing things and like to use unsafe compilers [Meltdown, Spectre come to mind], why can't they just use old versions of Boost?"
As it was answered, also many times: because we don't do support releases. Basically, if a bug is discovered, our recommendation is always "use a more recent Boost release". Of course, users can apply patches to their versions of Boost but this is a significant maintenance burden and may not be acceptable to everyone. Having new features and libraries might also be desirable. That the user's code base is C++03 doesn't necessarily mean it doesn't evolve.
There was, as far as I read it, considerable support to at least move to C++11, which is already 2 standards behind the current standard [and is by now fully supported on the main platforms]. Whatever is documented is not relevant, if the docs are out of date, they have to be updated. If every time this kind of question pops up, the answer is, "let's keep backward compatibility", then when are we gonna move to a newer standard? Or to put it differently, a direct question to you Andrey, at which point in time [which new std, 20, 23, 26, 29, 32???] do you think it will be opportune to move to C++11 and break with C++98 [because doing nothing will always be easier]?
If by "move" you mean actively stripping Boost from C++03 support then probably never. But as far as I'm concerned, Boost has moved to C++11 and later as soon as the first C++11 was accepted. At that point in time, the rest of Boost, still compatible with C++03, did not disappear and stayed relevant. C++03-compatible libraries are still a part of Boost and very much relevant, despite how many C++ versions have come out. Specifically for Boost.Log, it already does use some of the C++11 features, when available. And I even think it started doing so before C++11 was finalized. But I still consider C++03 compatibility a plus rather than a minus. On a personal note, I find this "C++11 holy cow" hype quite a pointless waste of breath (or... network bandwidth, I guess). There is no point in dropping libraries on the ground of C++03 compatibility, so that's never going to happen. Boost never rejected libraries that targeted newer C++ versions, that's not changing either. Declaring that we're not testing C++03 compilers anymore might make sense, but we actually do. So I don't quite understand what were the recent discussions about "dropping C++03" about. Just stop debating and start writing some great code, guys! Our users will be only happy. :)
I'm not adamantly against it, not to the point I would rewrite Boost.Log just to stay C++03 compatible. But it would seem that the C++11 requirement is not that necessary in Boost.Parameter either - you can just keep the existing code in C++03 mode it it'll work as before.
I guess, it's always possible to write more code [that's what you ask all maintainers to do] and work around the C++11 specificities?
It's a tradeoff, of course. In some cases, C++11 or whatever might be crucial for the library design or functionality. The particular case with Boost.Parameter doesn't seem to me like one, so yes, I'd *prefer* to keep the compatibility with C++03. If there appears a case that would make keeping the support for C++03 unreasonable (in Boost.Parameter or elswhere), I will accept it and Boost.Log, by induction, will become C++11-only.
On 11/3/18 5:17 PM, Andrey Semashev wrote:
On 11/3/18 4:21 PM, degski wrote:
On Sat, 3 Nov 2018 at 14:41, Andrey Semashev via Boost <boost@lists.boost.org <mailto:boost@lists.boost.org>> wrote:
On 11/3/18 2:47 PM, Cromwell Enage via Boost wrote: > Hello, Andrey. > > It's possible to retain the old code for C++03 compilers. Which ones do > your library users have?
I don't have this data. Boost.Log is documented to support gcc since 4.5 and MSVC since 8.0 SP1. It might be ok to raise the minimum requirement a bit, if it makes it easier to support in Boost.Parameter and other lower level libraries, but switching sraight to C++11 might be big deal for users.
The following question has been asked many times by many posters and there never is an answer: "Those users who want to stick to the old ways of doing things and like to use unsafe compilers [Meltdown, Spectre come to mind], why can't they just use old versions of Boost?"
As it was answered, also many times: because we don't do support releases. Basically, if a bug is discovered, our recommendation is always "use a more recent Boost release". Of course, users can apply patches to their versions of Boost but this is a significant maintenance burden and may not be acceptable to everyone.
Having new features and libraries might also be desirable. That the user's code base is C++03 doesn't necessarily mean it doesn't evolve.
There was, as far as I read it, considerable support to at least move to C++11, which is already 2 standards behind the current standard [and is by now fully supported on the main platforms]. Whatever is documented is not relevant, if the docs are out of date, they have to be updated. If every time this kind of question pops up, the answer is, "let's keep backward compatibility", then when are we gonna move to a newer standard? Or to put it differently, a direct question to you Andrey, at which point in time [which new std, 20, 23, 26, 29, 32???] do you think it will be opportune to move to C++11 and break with C++98 [because doing nothing will always be easier]?
If by "move" you mean actively stripping Boost from C++03 support then probably never. But as far as I'm concerned, Boost has moved to C++11 and later as soon as the first C++11 was accepted.
That should read "the first C++11 library was accepted".
At that point in time, the rest of Boost, still compatible with C++03, did not disappear and stayed relevant. C++03-compatible libraries are still a part of Boost and very much relevant, despite how many C++ versions have come out.
Specifically for Boost.Log, it already does use some of the C++11 features, when available. And I even think it started doing so before C++11 was finalized. But I still consider C++03 compatibility a plus rather than a minus.
On a personal note, I find this "C++11 holy cow" hype quite a pointless waste of breath (or... network bandwidth, I guess). There is no point in dropping libraries on the ground of C++03 compatibility, so that's never going to happen. Boost never rejected libraries that targeted newer C++ versions, that's not changing either. Declaring that we're not testing C++03 compilers anymore might make sense, but we actually do. So I don't quite understand what were the recent discussions about "dropping C++03" about. Just stop debating and start writing some great code, guys! Our users will be only happy. :)
I'm not adamantly against it, not to the point I would rewrite Boost.Log just to stay C++03 compatible. But it would seem that the C++11 requirement is not that necessary in Boost.Parameter either - you can just keep the existing code in C++03 mode it it'll work as before.
I guess, it's always possible to write more code [that's what you ask all maintainers to do] and work around the C++11 specificities?
It's a tradeoff, of course. In some cases, C++11 or whatever might be crucial for the library design or functionality. The particular case with Boost.Parameter doesn't seem to me like one, so yes, I'd *prefer* to keep the compatibility with C++03. If there appears a case that would make keeping the support for C++03 unreasonable (in Boost.Parameter or elswhere), I will accept it and Boost.Log, by induction, will become C++11-only.
Andrey Semashev wrote:
So I don't quite understand what were the recent discussions about "dropping C++03" about.
It appears that not many do. In short, the point is that much of the outside world thinks of Boost as a single thing. Our perspective as library maintainers is that libraries are independent, but that's not how others view them. To give you a specific example, if Parameter drops C++03 support, `b2 install` will fail on all compilers where C++03 is default because Log will fail to build. This is spelled "Boost 1.70 fails to build".
On 11/3/2018 10:47 AM, Peter Dimov via Boost wrote:
Andrey Semashev wrote:
So I don't quite understand what were the recent discussions about "dropping C++03" about.
It appears that not many do.
In short, the point is that much of the outside world thinks of Boost as a single thing. Our perspective as library maintainers is that libraries are independent, but that's not how others view them.
To give you a specific example, if Parameter drops C++03 support, `b2 install` will fail on all compilers where C++03 is default because Log will fail to build. This is spelled "Boost 1.70 fails to build".
I assume that the "dropping C++03 support" was also about building Boost for C++11 on up.
Edward Diener wrote:
To give you a specific example, if Parameter drops C++03 support, `b2 install` will fail on all compilers where C++03 is default because Log will fail to build. This is spelled "Boost 1.70 fails to build".
I assume that the "dropping C++03 support" was also about building Boost for C++11 on up.
This was a response to Andrey's question which was essentially about why we need to do anything on the Boost level to "drop C++03 support" rather than accomplishing the same thing organically by doing nothing and letting libraries drop it one by one. "Building Boost for C++11" is an action taken on the Boost level. It's not doing nothing and letting libraries drop it one by one. To preempt the follow-up question of why can't Log just alter its Jamfile to build for C++11 by default - because all of its dependencies will then refuse to install as it will attempt to build them for C++11, whereas they'll attempt to build themselves for C++03.
On 11/3/18 8:58 AM, Edward Diener via Boost wrote:
On 11/3/2018 10:47 AM, Peter Dimov via Boost wrote:
Andrey Semashev wrote:
So I don't quite understand what were the recent discussions about "dropping C++03" about.
It appears that not many do.
In short, the point is that much of the outside world thinks of Boost as a single thing. Our perspective as library maintainers is that libraries are independent, but that's not how others view them.
To give you a specific example, if Parameter drops C++03 support, `b2 install` will fail on all compilers where C++03 is default because Log will fail to build. This is spelled "Boost 1.70 fails to build".
I assume that the "dropping C++03 support" was also about building Boost for C++11 on up.
Hmmm - since C++ versions are backward compatible, almost any C++03 conforming program is also conforming to subsequent versions. The only exceptions are a very few deprecations (like auto). This leads me to not understand what it means to "drop C++03 support". If one want's to compile all of boost with C++11, it should work - subject to the few cases site above. I don't see any need for any action by anyone. Has anyone tried to build all of boost with C++ set to version 11? What are the results? If I had nothing else to do, I could do it. But it's a moot question for me in any case. Hmmm - then why am I replying here? I don't know. Robert Ramey
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On 03/11/2018 14:47, Peter Dimov via Boost wrote:
Andrey Semashev wrote:
So I don't quite understand what were the recent discussions about "dropping C++03" about.
It appears that not many do.
In short, the point is that much of the outside world thinks of Boost as a single thing. Our perspective as library maintainers is that libraries are independent, but that's not how others view them.
To give you a specific example, if Parameter drops C++03 support, `b2 install` will fail on all compilers where C++03 is default because Log will fail to build. This is spelled "Boost 1.70 fails to build".
Not if the Jamfile is marked up to require the C++11 (or whatever) features required - then it simply won't be built in 03 mode. Of course that may still be an issue if 03 is the compilers default mode :( John. --- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
On 11/3/2018 1:07 PM, John Maddock via Boost wrote:
On 03/11/2018 14:47, Peter Dimov via Boost wrote:
Andrey Semashev wrote:
So I don't quite understand what were the recent discussions about "dropping C++03" about.
It appears that not many do.
In short, the point is that much of the outside world thinks of Boost as a single thing. Our perspective as library maintainers is that libraries are independent, but that's not how others view them.
To give you a specific example, if Parameter drops C++03 support, `b2 install` will fail on all compilers where C++03 is default because Log will fail to build. This is spelled "Boost 1.70 fails to build".
Not if the Jamfile is marked up to require the C++11 (or whatever) features required - then it simply won't be built in 03 mode. Of course that may still be an issue if 03 is the compilers default mode :(
If we have announced that Boost will no longer support C++03, one of whose meanings is that compiling in C++03 mode may no longer work, then it is up to the end-user not to compile in C++03 mode, whether that is the compiler's default mode or not.
John.
--- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
On Sat, 3 Nov 2018 at 16:17, Andrey Semashev via Boost < boost@lists.boost.org> wrote:
If by "move" you mean actively stripping Boost from C++03 support then probably never.
I mean it in the same way Peter describes, progress in libraries [using C++11, or later standards] might make certain libraries fall by the way-side.
But as far as I'm concerned, Boost has moved to C++11 and later as soon as the first C++11 was accepted.
One of the problems are the libraries that got accepted into the std, take std::array. Moving to C++11 means in my view using the std-equivalent instead of the Boost version [which then also shift the maintenance burden of those libs to the compiler vendor]. When you keep saying "let's keep backward compatibility", this precludes doing that, or do conditional compilation, throughout. At that point in
time, the rest of Boost, still compatible with C++03, did not disappear and stayed relevant. C++03-compatible libraries are still a part of Boost and very much relevant, despite how many C++ versions have come out.
A library is unconditionally C++03 compatible, is code-smell. Move-semantics and/or perfect forwarding will in almost all cases improve performance, variadic templates improve [user-]usability. On a personal note, I find this "C++11 holy cow" hype quite a pointless
waste of breath (or... network bandwidth, I guess).
To me and many, C++11 is a big departure from C++98, while, once you actually dig in, one starts to realize that C++17 is an equally big step.
There is no point in dropping libraries on the ground of C++03 compatibility, so that's never going to happen.
Sure not, like Edward also says, if it works, it works, no need to do anything. But that was not what you were saying, you said, please write some more code so that Boost.Parameter maintains C++03 compatibility.
Just stop debating and start writing some great code, guys! Our users will be only happy. :)
The thing is, that it's much easier to write great code using C++11, 14 and certainly C++17.
It's a tradeoff, of course. In some cases, C++11 or whatever might be crucial for the library design or functionality. The particular case with Boost.Parameter doesn't seem to me like one, so yes, I'd *prefer* to keep the compatibility with C++03.
At every junction it will always just seem a small step to keep C++03 compatibility, but eventually all those small steps [would] make a big journey, and it's not one that was taken, because at every crossing we said, let's not do that. I've been using Boost since about 2009 I would say.
If there appears a case that would make keeping the support for C++03 unreasonable (in Boost.Parameter or elswhere), I will accept it and Boost.Log, by induction, will become C++11-only.
Peter proposed to fork Boost.Parameter03, which seems reasonable to me, but then begs the question, why not for the whole of Boost and go Boost 2.0 [discussed many times I know]. degski -- *“If something cannot go on forever, it will stop" - Herbert Stein*
Just stop debating and start writing some great code, guys! Our users will be only happy. :)
The thing is, that it's much easier to write great code using C++11, 14 and certainly C++17.
minus toolchain bugs. consider std::atomic for example: clang/libcxx had a broken implementation until mid 2014, while msvc had a but until 2016. using new standards early one may have to pay the price of the early adopters. that said, in 2018 boost should be able to safely move to c++11.
On 11/4/18 11:03 AM, degski wrote:
On Sat, 3 Nov 2018 at 16:17, Andrey Semashev via Boost <boost@lists.boost.org <mailto:boost@lists.boost.org>> wrote:
If by "move" you mean actively stripping Boost from C++03 support then probably never.
I mean it in the same way Peter describes, progress in libraries [using C++11, or later standards] might make certain libraries fall by the way-side.
Sorry, I still don't understand. What exactly do you mean by "fall by the way-side"? Is it that they get broken? Or become irrelevant? Or something else?
But as far as I'm concerned, Boost has moved to C++11 and later as soon as the first C++11 was accepted.
One of the problems are the libraries that got accepted into the std, take std::array. Moving to C++11 means in my view using the std-equivalent instead of the Boost version [which then also shift the maintenance burden of those libs to the compiler vendor]. When you keep saying "let's keep backward compatibility", this precludes doing that, or do conditional compilation, throughout.
In many cases I don't see the advantage in switching to std equivalents. E.g. when boost::array is used internally, there is no reason to switch to std::array as it doesn't affect users and doesn't offer any benefits to the maintainer. On the contrary, I often trust Boost implementation more because (a) it is tested and maintained by us (i.e. is under our control) and (b) it is a single implementation as opposed to multiple std libraries with their own quirks and bugs. In some cases, Boost equivalents simply work better. However, the case in point is not what you describe. It is not about standard library features that could be used to improve user experience. It is about a core language feature, which can be used optionally and even emulated in C++03.
At that point in time, the rest of Boost, still compatible with C++03, did not disappear and stayed relevant. C++03-compatible libraries are still a part of Boost and very much relevant, despite how many C++ versions have come out.
A library is unconditionally C++03 compatible, is code-smell.
I strongly disagree. There are plenty state of the art Boost libraries that support C++03. Boost.Intrusive, Boost.ASIO, Boost.Spirit, Boost.Interprocess to name just a few. Judging code quality by the C++ version it is compatible with is terribly misguided, IMO.
Move-semantics and/or perfect forwarding will in almost all cases improve performance, variadic templates improve [user-]usability.
Sure, and most of the time these features can be used optionally. And I think most of the actively maintained libraries have employed some C++11 features while keeping the compatibility with C++03.
On a personal note, I find this "C++11 holy cow" hype quite a pointless waste of breath (or... network bandwidth, I guess).
To me and many, C++11 is a big departure from C++98, while, once you actually dig in, one starts to realize that C++17 is an equally big step.
I wouldn't call it a departure, more a move (no pun intended) in the direction everyone wanted and oftentimes already used the language. And I'm rather used to C++17, so I actually see the difference in the field. It doesn't make me choke every time I use a library that happen to be compatible with C++03, in fact I barely even notice. So I disagree with everyone who thinks such libraries are code smell and don't deserve to live under the sun.
There is no point in dropping libraries on the ground of C++03 compatibility, so that's never going to happen.
Sure not, like Edward also says, if it works, it works, no need to do anything. But that was not what you were saying, you said, please write some more code so that Boost.Parameter maintains C++03 compatibility.
That was not what I was saying. I was saying "keep the existing code or use Boost.Move", in a rather soft way of asking, BTW.
Just stop debating and start writing some great code, guys! Our users will be only happy. :)
The thing is, that it's much easier to write great code using C++11, 14 and certainly C++17.
Then go ahead and do that. As I said, Boost doesn't refuse libraries on the basis of the minimum required C++ version.
Peter proposed to fork Boost.Parameter03, which seems reasonable to me, but then begs the question, why not for the whole of Boost and go Boost 2.0 [discussed many times I know].
And I replied that I'd rather switch to C++11 than have a fork.
My 2c on this kind of question, for what it's worth, is that each new boost release should only target the current standard at time of release and up. This will force users, and more importantly *compiler vendors* to keep up and stop dragging us all back to the stone age. Boost is *the de-facto standard in c++*. If it demands c++17, compiler vendors will deliver c++17 - otherwise they will go out of business. Libraries such as boost::asio would half in size if they only had to target c++17. If boost only supported standards-compliant compilers, 90% of the unreadable polyfill conditional compilation could be eradicated. This would allow contributors to embrace the brave new world without being distracted by putting band-aids on the old one. On Sun, 4 Nov 2018 at 16:35, Andrey Semashev via Boost < boost@lists.boost.org> wrote:
On Sat, 3 Nov 2018 at 16:17, Andrey Semashev via Boost <boost@lists.boost.org <mailto:boost@lists.boost.org>> wrote:
If by "move" you mean actively stripping Boost from C++03 support
On 11/4/18 11:03 AM, degski wrote: then
probably never.
I mean it in the same way Peter describes, progress in libraries [using C++11, or later standards] might make certain libraries fall by the way-side.
Sorry, I still don't understand. What exactly do you mean by "fall by the way-side"? Is it that they get broken? Or become irrelevant? Or something else?
But as far as I'm concerned, Boost has moved to C++11 and later as soon as the first C++11 was accepted.
One of the problems are the libraries that got accepted into the std, take std::array. Moving to C++11 means in my view using the std-equivalent instead of the Boost version [which then also shift the maintenance burden of those libs to the compiler vendor]. When you keep saying "let's keep backward compatibility", this precludes doing that, or do conditional compilation, throughout.
In many cases I don't see the advantage in switching to std equivalents. E.g. when boost::array is used internally, there is no reason to switch to std::array as it doesn't affect users and doesn't offer any benefits to the maintainer. On the contrary, I often trust Boost implementation more because (a) it is tested and maintained by us (i.e. is under our control) and (b) it is a single implementation as opposed to multiple std libraries with their own quirks and bugs. In some cases, Boost equivalents simply work better.
However, the case in point is not what you describe. It is not about standard library features that could be used to improve user experience. It is about a core language feature, which can be used optionally and even emulated in C++03.
At that point in time, the rest of Boost, still compatible with C++03, did not
disappear
and stayed relevant. C++03-compatible libraries are still a part of Boost and very much relevant, despite how many C++ versions have come out.
A library is unconditionally C++03 compatible, is code-smell.
I strongly disagree. There are plenty state of the art Boost libraries that support C++03. Boost.Intrusive, Boost.ASIO, Boost.Spirit, Boost.Interprocess to name just a few. Judging code quality by the C++ version it is compatible with is terribly misguided, IMO.
Move-semantics and/or perfect forwarding will in almost all cases improve performance, variadic templates improve [user-]usability.
Sure, and most of the time these features can be used optionally. And I think most of the actively maintained libraries have employed some C++11 features while keeping the compatibility with C++03.
On a personal note, I find this "C++11 holy cow" hype quite a
pointless
waste of breath (or... network bandwidth, I guess).
To me and many, C++11 is a big departure from C++98, while, once you actually dig in, one starts to realize that C++17 is an equally big step.
I wouldn't call it a departure, more a move (no pun intended) in the direction everyone wanted and oftentimes already used the language. And I'm rather used to C++17, so I actually see the difference in the field. It doesn't make me choke every time I use a library that happen to be compatible with C++03, in fact I barely even notice. So I disagree with everyone who thinks such libraries are code smell and don't deserve to live under the sun.
There is no point in dropping libraries on the ground of C++03 compatibility, so that's never going to happen.
Sure not, like Edward also says, if it works, it works, no need to do anything. But that was not what you were saying, you said, please write some more code so that Boost.Parameter maintains C++03 compatibility.
That was not what I was saying. I was saying "keep the existing code or use Boost.Move", in a rather soft way of asking, BTW.
Just stop debating and start writing some great code, guys! Our users will be only happy. :)
The thing is, that it's much easier to write great code using C++11, 14 and certainly C++17.
Then go ahead and do that. As I said, Boost doesn't refuse libraries on the basis of the minimum required C++ version.
Peter proposed to fork Boost.Parameter03, which seems reasonable to me, but then begs the question, why not for the whole of Boost and go Boost 2.0 [discussed many times I know].
And I replied that I'd rather switch to C++11 than have a fork.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- Richard Hodges hodges.r@gmail.com
On 4/11/2018 23:00, Richard Hodges wrote:
My 2c on this kind of question, for what it's worth, is that each new boost release should only target the current standard at time of release and up. This will force users, and more importantly *compiler vendors* to keep up and stop dragging us all back to the stone age.
Boost is *the de-facto standard in c++*. If it demands c++17, compiler vendors will deliver c++17 - otherwise they will go out of business.
This is an excellent way to encourage application writers to stop using Boost entirely. And hence for Boost to go out of business.
On 11/3/18 4:49 PM, Peter Dimov via Boost wrote:
Andrey Semashev wrote:
I'm not adamantly against it, not to the point I would rewrite Boost.Log just to stay C++03 compatible.
Going that far may be unnecessary; we could just fork a `parameter03` so that C++03 libraries can keep using it.
Technically, this is a possibility. Practically, I don't think this would be good for Boost.Parameter users. The forks will have to have separate interfaces to not clash. Then there are interoperability issues. No, if we definitely don't want to preserve C++03 compatibility then let's just switch to C++11 in (the only) Boost.Parameter and declare downstream libraries C++11 as well.
On 11/2/2018 10:17 PM, Cromwell Enage via Boost wrote:
Hi, everyone.
The end of section 3.2.1 of the current Boost.Parameter home page tutorial notes "that because of the forwarding problem, parameter::parameters::operator() can't accept non-const rvalues". I've submitted a PR to the develop branch on GitHub that would grant Boost.Parameter the ability to support perfect forwarding and eliminate this issue. However, the PR uses rvalue references (in parameter::keyword, parameter::parameters, and the code generation macros) and variadic templates (in parameter::parameters and the code generation macros). With the exception of BOOST_PARAMETER_TEMPLATE_KEYWORD, the PR would make Boost.Parameter a C++11 library. As a result--based on < http://pdimov.github.io/boostdep-report/develop/parameter.html#reverse-dependencies>--the following Boost libraries known to use Boost.Parameter would also become C++11:
Boost.Accumulators Boost.Convert Boost.Graph Boost.Heap Boost.Log Boost.MetaStateMachine or Boost.MSM Boost.Parameter_Python Boost.Signals2
I'd like to hear from everyone else, especially the maintainers and users of these libraries, if it's okay for Boost.Parameter to go C++11 and above only or if C++03 support is still necessary.
I am really surprised that after he discussion and general agreement that Boost would be dropping support for C++03 that there would still be objections for a Boost library going from C++03 to C++11, as Parameter wishes to do under the guidance of Cromwell Enage. Was not the discussion about dropping support for C++03 a pretty clear indication that retaining backward compatibility for C++03, in a library going to C++11, should no longer be desired ? At some point retaining backward compatibility for old C++ standards and old compiler implementations becomes a liability for a library and I see nothing wrong with that library moving toward more modern C++. If some other library, with a dependency on Parameter and still supporting C++03, is considered there are three possibilities: 1) Change code so that Parameter is no longer a dependency 2) Change code so that only Parameter header files which do not contain any C++11 constructs are included. 3) Become a C++11 library, meaning that C++03 is no longer supported. Given our discussion of Boost dropping support for C++03 the worst case scenario of item 3) can never be wrong.
Cromwell D. Enage
On Sunday, November 4, 2018, Edward Diener wrote:
I am really surprised that after he discussion and general agreement that Boost would be dropping support for C++03 that there would still be objections for a Boost library going from C++03 to C++11, as Parameter wishes to do under the guidance of Cromwell Enage. Was not the discussion about dropping support for C++03 a pretty clear indication that retaining backward compatibility for C++03, in a library going to C++11, should no longer be desired ?
Is this a case of the official maintainer of Parameter choosing to drop C++03 and make it a C++11+-only library? If so, under the model we discussed and that had general agreement, nobody else can block this from happening. i.e. There can be no objection. It would be the system working as intended. Parameter would become C++11+-only and affected libraries would have to do the same or drop the dependency on Parameter. However: If this is a case of a library with no official maintainer, but where a prospective contributor (or some community maintenance team) wishes to do the above, and then solicits blessing/approval from affected libraries' maintainers, and then one or more of those maintainers prefers to find a solution that will retain C++03 compatibility: Then whatever compromise was agreed upon between these parties would also be the system working as intended. Glen
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Cromwell Enage via Boost Sent: 03 November 2018 02:18 To: boost@lists.boost.org Cc: Cromwell Enage Subject: [boost] [parameter] Go C++11 and above only, or keep C++03 support?
Hi, everyone.
The end of section 3.2.1 of the current Boost.Parameter home page tutorial notes "that because of the forwarding problem, parameter::parameters::operator() can't accept non-const rvalues". I've submitted a PR to the develop branch on GitHub that would grant Boost.Parameter the ability to support perfect forwarding and eliminate this issue. However, the PR uses rvalue references (in parameter::keyword, parameter::parameters, and the code generation macros) and variadic templates (in parameter::parameters and the code generation macros). With the exception of BOOST_PARAMETER_TEMPLATE_KEYWORD, the PR would make Boost.Parameter a C++11 library. As a result--based on < http://pdimov.github.io/boostdep-report/develop/parameter.html#reverse-dependencies>--the following Boost libraries known to use Boost.Parameter would also become C++11:
Boost.Accumulators Boost.Convert Boost.Graph Boost.Heap Boost.Log Boost.MetaStateMachine or Boost.MSM Boost.Parameter_Python Boost.Signals2
I'd like to hear from everyone else, especially the maintainers and users of these libraries, if it's okay for Boost.Parameter to go C++11 and above only or if C++03 support is still necessary.
My view is that it is up to you to decide (but asking for views is good too). If it is not too difficult to make it continue to be C++03 compatible and yet allow C++11 (or higher) improvements then you should do this. For example, if you can easily write #ifdef BOOST_NO_C11_feature do the current C++03 stuff (even full function definition) #else do the enhanced version #endif then you should do so, in order to avoid, as RyanAir CEO Michael O'Leary put it "We should try to eliminate things that unnecessarily piss people off," (See https://www.reuters.com/article/us-ryanair/ryanair-unveils-new-strategy-be-n... for sordid details) but if this proves difficult (and trying it may be the only way to find out) then you should announce that it will require some C++11 feature one release ahead of the change. You should change the jamfile to require the new C++11 feature(s) as this demo https://www.boost.org/doc/libs/1_68_0/libs/config/doc/html/boost_config/buil... This will leave a blank in the regression matrix for those platforms that don't support this C++11 feature that will flag to users that it won't work and they need to freeze their Boost at this version, or get a more up-to-date compiler. Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830
-----Original Message----- From: Boost <boost-bounces@lists.boost.org> On Behalf Of Paul A. Bristow via Boost Sent: Monday, November 5, 2018 1:26 PM
My view is that it is up to you to decide (but asking for views is good too).
If it is not too difficult to make it continue to be C++03 compatible and yet allow C++11 (or higher) improvements then you should do this.
For example, if you can easily write
#ifdef BOOST_NO_C11_feature
do the current C++03 stuff (even full function definition)
#else
do the enhanced version
#endif
then you should do so, in order to avoid, as RyanAir CEO Michael O'Leary put it
"We should try to eliminate things that unnecessarily piss people off,"
(See https://www.reuters.com/article/us-ryanair/ryanair-unveils-new-strategy-be-n... customers-idUSBRE98J0DF20130920 for sordid details)
Just saying. #ifdef BOOST_NO_C11_feature can become extremely annoying for the user, because you effectively have to make sure that all translation units including that header have to be compiled with the same c++ standard setting (yes, it isn't actually necessary when you are careful, but the complexity and testing overhead will probably negate much of the advantage you gain by using c++11 features instead of 03 workarounds).
but if this proves difficult (and trying it may be the only way to find out) then you should announce that it will require some C++11 feature one release ahead of the change.
I'd give a two release heads up (Announce the change in 1.69, put an compilation warning in 1.70 and then start using the c++11 features in 1.71). Although there was tentatively agreement on the ML that c++03 support should be dropped on a general boost-wide level and that that would also mean that maintainers can drop their individual c++03 support without prior announcement, this has not yet become official policy or widely announced, so I'd tread carefully here. Best Mike
On Mon, 5 Nov 2018 at 14:26, Paul A. Bristow via Boost < boost@lists.boost.org> wrote:
then you should do so, in order to avoid, as RyanAir CEO Michael O'Leary put it
"We should try to eliminate things that unnecessarily piss people off,"
(See https://www.reuters.com/article/us-ryanair/ryanair-unveils-new-strategy-be-n... for sordid details)
Michael O'Leary talks a lot of shit, the quoted article is from 2013, in the meanwhile Michael O'Leary has come up with ideas like [but not limited to], travel standing up (strapped in on departure and arrival), paying to go to the loo and of course the 6-monthly change in baggage-policy [can he ever make up his mind?]. His company also violates [continuously] EU labor- and tax-law, basically takes people for granted, both personnel and customers, and makes DT look civilized. Let's not try and learn from Michael O'Leary, because in that case you'd have to pay extra to have C++03 support and Boost would be fully C++17. degski -- *“If something cannot go on forever, it will stop" - Herbert Stein*
On Mon, 5 Nov 2018 at 20:38, degski via Boost <boost@lists.boost.org> wrote:
On Mon, 5 Nov 2018 at 14:26, Paul A. Bristow via Boost < boost@lists.boost.org> wrote:
then you should do so, in order to avoid, as RyanAir CEO Michael O'Leary put it
"We should try to eliminate things that unnecessarily piss people off,"
(See
https://www.reuters.com/article/us-ryanair/ryanair-unveils-new-strategy-be-n...
for sordid details)
Michael O'Leary talks a lot of shit, the quoted article is from 2013, in the meanwhile Michael O'Leary has come up with ideas like [but not limited to], travel standing up (strapped in on departure and arrival), paying to go to the loo and of course the 6-monthly change in baggage-policy [can he ever make up his mind?]. His company also violates [continuously] EU labor- and tax-law, basically takes people for granted, both personnel and customers, and makes DT look civilized.
Let's not try and learn from Michael O'Leary, because in that case you'd have to pay extra to have C++03 support and Boost would be fully C++17.
On this I am fully with Michael O'Leary. The argument for staying with c++03 is the same as the argument for staying with the biplane. Fun for nostalgic airshows but utterly useless as a business tool.
degski -- *“If something cannot go on forever, it will stop" - Herbert Stein*
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
-- Richard Hodges hodges.r@gmail.com office: +442032898513 home: +376841522 mobile: +376380212 (this will be *expensive* outside Andorra!) skype: madmongo facebook: hodges.r
-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Richard Hodges via Boost Sent: 05 November 2018 17:20 To: boost@lists.boost.org Cc: Richard Hodges Subject: Re: [boost] [parameter] Go C++11 and above only, or keep C++03 support?
On Mon, 5 Nov 2018 at 20:38, degski via Boost <boost@lists.boost.org> wrote:
On Mon, 5 Nov 2018 at 14:26, Paul A. Bristow via Boost < boost@lists.boost.org> wrote:
then you should do so, in order to avoid, as RyanAir CEO Michael O'Leary put it
"We should try to eliminate things that unnecessarily piss people off,"
(See
https://www.reuters.com/article/us-ryanair/ryanair-unveils-new-strategy-be-n...
for sordid details)
Michael O'Leary talks a lot of shit, the quoted article is from 2013, in the meanwhile Michael O'Leary has come up with ideas like [but not limited to], travel standing up (strapped in on departure and arrival), paying to go to the loo and of course the 6-monthly change in baggage-policy [can he ever make up his mind?]. His company also violates [continuously] EU labor- and tax-law, basically takes people for granted, both personnel and customers, and makes DT look civilized.
Let's not try and learn from Michael O'Leary, because in that case you'd have to pay extra to have C++03 support and Boost would be fully C++17.
On this I am fully with Michael O'Leary. The argument for staying with c++03 is the same as the argument for staying with the biplane. Fun for nostalgic airshows but utterly useless as a business tool.
You guys have obviously never booked, tried to boo, or even worse, flown with RyanAir!
Michael O'Leary talks a lot of shit, the quoted article is from 2013,
indeed, and that was why they shut him up! (For a while at least). However, I still believe "We should try to eliminate things that unnecessarily piss people off," and gratuitously making things C++11 will undoubtedly do that for some, while NOT using C++XX enhancements with annoy others. So if it isn’t a load of trouble, do both. If it is BIG trouble, do the C++XX best thing. Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830
Thanks for your feedback, everyone! To answer Glen Fernandes's question, I am not the official maintainer, just a contributor who is willing to help improve a Boost library. I've submitted a separate pull request that includes the C++03 workarounds. I did this in case our official stance for 1.70 is to keep C++03 support, and also in an effort to ensure that the downstream libraries, a few of which I also use, won't break (or at least won't have their tests broken). Regarding Paul Bristow's input, it hasn't been a load of trouble, but it was bad enough. I'll leave it up to the official maintainer(s) to decide which PR to approve. That being said, should the new PR be the chosen one, any new features I plan to add from that point on will not include explicit C++03 workarounds. Cromwell D. Enage
On 11/6/18 9:35 PM, Cromwell Enage via Boost wrote:
Thanks for your feedback, everyone!
To answer Glen Fernandes's question, I am not the official maintainer, just a contributor who is willing to help improve a Boost library.
I've submitted a separate pull request that includes the C++03 workarounds. I did this in case our official stance for 1.70 is to keep C++03 support, and also in an effort to ensure that the downstream libraries, a few of which I also use, won't break (or at least won't have their tests broken). Regarding Paul Bristow's input, it hasn't been a load of trouble, but it was bad enough. I'll leave it up to the official maintainer(s) to decide which PR to approve. That being said, should the new PR be the chosen one, any new features I plan to add from that point on will not include explicit C++03 workarounds.
Thank you Cromwell.
participants (14)
-
Andrey Semashev -
Cromwell Enage -
degski -
Edward Diener -
Gavin Lambert -
Glen Fernandes -
John Maddock -
Mike Dev -
Paul A. Bristow -
Peter Dimov -
Rene Rivera -
Richard Hodges -
Robert Ramey -
Tim Blechmann