Any objections to making C++14 the current baseline for Boost support and testing?
Pursuant of discussion elsewhere: Does anyone have any concrete objections to Boost moving to a C++14 baseline? This would mean: * Library authors can drop and remove all support for pre-C++14 compilers after a suitable deprecation notice in place for say 3 releases. * The community maintenance team can likewise drop pre-C++14 support from community maintained / orphan libaries. * CI tests no longer need report pre-C++14 results. * From the next release onward, the boost super-project should clearly announce in our release notes, that C++11 and earlier support may no longer be available from the start of 2023. Thoughts? Thanks, John Maddock.
I'm not against breaking compatibility with older c++-versions at all, but given that c++-14 has so few new features compared to c++-11 I do think that it may be better to bump the baseline to c++-17 directly. Whether we should do that _now_ is another matter. IMNSHO c++17 has been out for long enough that you'd expect most people to now have a compiler that can handle it. On Fri, 2022-05-06 at 09:19 +0100, John Maddock via Boost-users wrote:
Pursuant of discussion elsewhere:
Does anyone have any concrete objections to Boost moving to a C++14 baseline?
This would mean:
* Library authors can drop and remove all support for pre-C++14 compilers after a suitable deprecation notice in place for say 3 releases.
* The community maintenance team can likewise drop pre-C++14 support from community maintained / orphan libaries.
* CI tests no longer need report pre-C++14 results.
* From the next release onward, the boost super-project should clearly announce in our release notes, that C++11 and earlier support may no longer be available from the start of 2023.
Thoughts?
Thanks, John Maddock.
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org https://lists.boost.org/mailman/listinfo.cgi/boost-users
On 06/05/2022 09:25, Martijn Otto via Boost-users wrote:
I'm not against breaking compatibility with older c++-versions at all, but given that c++-14 has so few new features compared to c++-11 I do think that it may be better to bump the baseline to c++-17 directly.
Whether we should do that _now_ is another matter. IMNSHO c++17 has been out for long enough that you'd expect most people to now have a
There's been some discussion on the develop list about this: I confess I was in your camp, but it's been (correctly) pointed out to me that C++14 is the std version that actually made many of the C++11 features usable ;) Plus compiler support for gcc and msvc tended to arrive at both C++14 and 11 together in the same release (gcc had pre-C++11 support earlier, but there are enough bugs for it for us to not want to be targeting pre-gcc-5). Both compilers are also c++14 by default at present, I realize that will change shortly, but we're not quite there yet. Thanks, John.
Hello,
Does anyone have any concrete objections to Boost moving to a C++14 baseline?
We are still using boost in code cross compiled for legacy target devices, and the toolchain does not support C++14. We are currently not using latest boost libraries, and won't be affected by this change immediately, but we won't be able to update our copy of boost to a recent version. So, I would not like to see support for pre C++14 to be dropped, but it would not be a show stopper for us, now, just fewer update options in the future. The benefit to the source code and future development of boost might outweigh my objection. Klebsch Mario Funktion | R&D Tel: +49 (0) 531 38 701 718 Raum: Braunschweig, E20 Diese E-Mail und die an sie angehängten Dateien sind ausschließlich für Personen oder Institutionen bestimmt, deren Namen oben aufgeführt sind. Sie können Informationen enthalten, die durch das Berufsgeheimnis geschützt sind und deren Weitergabe strengstens untersagt ist. Jede elektronische Nachricht kann geändert werden. ACTIA lehnt jede Verantwortung für diese Nachricht ab. Der Inhalt dieser Nachricht stellt keine Verpflichtung seitens unseres Unternehmens dar. Wenn Sie kein Empfänger sind, weisen wir Sie darauf hin, dass das Lesen, Vervielfältigen oder Verteilen strengstens untersagt ist. Wir bitten Sie daher, uns umgehend über diesen Brief zu informieren und diese Nachricht sowie eventuell beigefügte Unterlagen aus Ihrem Postfach zu löschen. Danke. This e-mail and the files attached to it are intended exclusively for persons or institutions whose names are listed above. They may contain information that is protected by professional secrecy and the disclosure of which is strictly prohibited. Any electronic message can be modified. ACTIA declines all responsibility for this message. The content of this message does not represent a commitment on the part of our company. If you are not a recipient, we would like to point out that reading, copying or distribution is strictly prohibited. We therefore ask you to inform us immediately about this letter and to delete this message and any accompanying documents from your mailbox. Thank you.
On 06/05/2022 09:30, Klebsch, Mario via Boost-users wrote:
Hello,
Does anyone have any concrete objections to Boost moving to a C++14 baseline? We are still using boost in code cross compiled for legacy target devices, and the toolchain does not support C++14. We are currently not using latest boost libraries, and won't be affected by this change immediately, but we won't be able to update our copy of boost to a recent version.
Do you mind if I ask which libraries you're using? Thanks, John.
Hello,
Do you mind if I ask which libraries you're using?
Its fairly basic stuff like boost::shared_ptr<>, boost::thread, boost::conditionvariable, boost::chrono, boost:posix_time, boost::system::error_code and (more advanced) boost::asio. Klebsch Mario Funktion | R&D Tel: +49 (0) 531 38 701 718 Raum: Braunschweig, E20 Diese E-Mail und die an sie angehängten Dateien sind ausschließlich für Personen oder Institutionen bestimmt, deren Namen oben aufgeführt sind. Sie können Informationen enthalten, die durch das Berufsgeheimnis geschützt sind und deren Weitergabe strengstens untersagt ist. Jede elektronische Nachricht kann geändert werden. ACTIA lehnt jede Verantwortung für diese Nachricht ab. Der Inhalt dieser Nachricht stellt keine Verpflichtung seitens unseres Unternehmens dar. Wenn Sie kein Empfänger sind, weisen wir Sie darauf hin, dass das Lesen, Vervielfältigen oder Verteilen strengstens untersagt ist. Wir bitten Sie daher, uns umgehend über diesen Brief zu informieren und diese Nachricht sowie eventuell beigefügte Unterlagen aus Ihrem Postfach zu löschen. Danke. This e-mail and the files attached to it are intended exclusively for persons or institutions whose names are listed above. They may contain information that is protected by professional secrecy and the disclosure of which is strictly prohibited. Any electronic message can be modified. ACTIA declines all responsibility for this message. The content of this message does not represent a commitment on the part of our company. If you are not a recipient, we would like to point out that reading, copying or distribution is strictly prohibited. We therefore ask you to inform us immediately about this letter and to delete this message and any accompanying documents from your mailbox. Thank you.
On 7/05/2022 00:08, Klebsch, Mario wrote:
Do you mind if I ask which libraries you're using?
Its fairly basic stuff like boost::shared_ptr<>, boost::thread, boost::conditionvariable, boost::chrono, boost:posix_time, boost::system::error_code and (more advanced) boost::asio.
You would still be able to use older versions of Boost (although you may need to build and/or package it yourself and not assume that system-Boost can continue to be used for posix systems). Though perhaps if there's a clean break, distributions and package maintainers might be more willing to distribute both legacy and new packages for a while. For embedded software, that's probably less of a concern since you're more likely to be building and packaging everything yourself anyway, or at least adding Boost to your existing list of custom packages is unlikely to be difficult. Most of the libraries you named there are unlikely to get many new features or even bugfixes over time (or at least probably not ones that you would care about); except perhaps for Asio, which might morph into something even more strange and peculiar in line with the C++23 networking libary -- and as such you might not want such changes anyway.
Personally, I always thought that, since C++11, Boost was there to allow people to be able to use some of the C++11 -> features without needing a C++11 -> compiler, so it seems a little odd to seemingly abandon those people who're using it for that purpose. However, as I've been using C++17 for some time now, it probably doesn't really affect me. John On 06/05/2022 09:19, John Maddock via Boost-users wrote:
Pursuant of discussion elsewhere:
Does anyone have any concrete objections to Boost moving to a C++14 baseline?
This would mean:
* Library authors can drop and remove all support for pre-C++14 compilers after a suitable deprecation notice in place for say 3 releases.
* The community maintenance team can likewise drop pre-C++14 support from community maintained / orphan libaries.
* CI tests no longer need report pre-C++14 results.
* From the next release onward, the boost super-project should clearly announce in our release notes, that C++11 and earlier support may no longer be available from the start of 2023.
Thoughts?
Thanks, John Maddock.
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org https://lists.boost.org/mailman/listinfo.cgi/boost-users
On 06/05/2022 10:19, John McCabe via Boost-users wrote:
Personally, I always thought that, since C++11, Boost was there to allow people to be able to use some of the C++11 -> features without needing a C++11 -> compiler, so it seems a little odd to seemingly abandon those people who're using it for that purpose.
That was an early goal yes, but much of that (TR1 library for example) has been deprecated for some time.
Hi, Would there be an intent to increase the support of new standard libraries by boost libraries? On top of my head, I think first to shared_ptr<> and error_code. Mixing std libraries and their equivalent in boost is most of the time tedious. Concretely, it becomes difficult to integrate components and interoperate them when some adopt std::error_code while others must stick boost::system::error_code due to constraints (mainly asio and beast. We thought to migrate to the standalone asio, but there is no equivalent for beast). Even if some efforts have been done to convert boost error_code to std ones, this is far from ideal. And as mentioned by Martijn Otto, I would opt also for jumping directly to C++17. BTW, could you give the list of orphan libraries? My 2 cents On 06/05/2022 10:19, John Maddock via Boost-users wrote:
Pursuant of discussion elsewhere:
Does anyone have any concrete objections to Boost moving to a C++14 baseline?
This would mean:
* Library authors can drop and remove all support for pre-C++14 compilers after a suitable deprecation notice in place for say 3 releases.
* The community maintenance team can likewise drop pre-C++14 support from community maintained / orphan libaries.
* CI tests no longer need report pre-C++14 results.
* From the next release onward, the boost super-project should clearly announce in our release notes, that C++11 and earlier support may no longer be available from the start of 2023.
Thoughts?
Thanks, John Maddock.
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org https://lists.boost.org/mailman/listinfo.cgi/boost-users
Christophe B via Boost-users <boost-users@lists.boost.org> wrote:
Hi,
Would there be an intent to increase the support of new standard libraries by boost libraries? On top of my head, I think first to shared_ptr<> and error_code. Mixing std libraries and their equivalent in boost is most of the time tedious. Concretely, it becomes difficult to integrate components and interoperate them when some adopt std::error_code while others must stick boost::system::error_code due to constraints (mainly asio and beast. We thought to migrate to the standalone asio, but there is no equivalent for beast). Even if some efforts have been done to convert boost error_code to std ones, this is far from ideal.
And as mentioned by Martijn Otto, I would opt also for jumping directly to C++17.
In my company at least, we're still stuck with C++14 because some customers use old toolchains and we use boost. So requiring C++17 would be annoying. Boost is nice for projects that can't use a recent C++ standard as it provides things like boost::optional, boost::variant, boost::filesystem (etc.) instead of the std ones which require newer C++ standards. Dominique
On Fri, May 6, 2022 at 1:20 AM John Maddock via Boost-users <boost-users@lists.boost.org> wrote:
Does anyone have any concrete objections to Boost moving to a C++14 baseline?
Yes. If any of Boost.Beast's dependencies requires C++14, then Beast will require C++14. I am not quite ready to force half of Beast's existing userbase to upgrade to C++14 or later, or not use newer versions of Boost. Source: <https://blog.jetbrains.com/wp-content/uploads/2021/07/cpp11_migration.png> Thanks
participants (1)
-
Christophe B -
Dominique Pellé -
Gavin Lambert -
John Maddock -
John McCabe -
Klebsch, Mario -
Martijn Otto -
Vinnie Falco