-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RFC: Increase C++ version to C++17 #106
Comments
I'm on board. I remember when we made the decision to support C++11 five or six years ago! Edit: found it! Not sure why I felt like looking it up, curiosity got the best of me. |
See discussion on uptane/aktualizr#106 Full C++17 support came in gcc 8 (although most of it was present in gcc 7 already. In terms of our likely target platforms already ship that: * Debian oldstable shipped with gcc-10. * The oldest supported Yocto release is Dunfell, which shipped gcc 9.5 That suggests that getting a C++17 compiler shouldn't be a huge problem for our downstream. Why not go further? C++20 support would require gcc 10 or 11, and while we could go that far it seems like we should be conservative by default.
Brings back good memories! I've been working on a big series to remove the deprecated openssl functions, and I have this upgrade as a part of that at the moment. It is still WIP, but the (unstable) branch is feat/openssl3 on my github. It is currently built on the Toradex fork, but I have another task to rebase that and bring it close to upstream. |
That's not an issue for Foundries at all, we moved to |
I would be conservative too, unless there are strong benefits in switching to |
See discussion on uptane/aktualizr#106 Full C++17 support came in gcc 8 (although most of it was present in gcc 7 already. In terms of our likely target platforms already ship that: * Debian oldstable shipped with gcc-10. * The oldest supported Yocto release is Dunfell, which shipped gcc 9.5 That suggests that getting a C++17 compiler shouldn't be a huge problem for our downstream. Why not go further? C++20 support would require gcc 10 or 11, and while we could go that far it seems like we should be conservative by default.
See discussion on #106 Full C++17 support came in gcc 8 (although most of it was present in gcc 7 already. In terms of our likely target platforms already ship that: * Debian oldstable shipped with gcc-10. * The oldest supported Yocto release is Dunfell, which shipped gcc 9.5 That suggests that getting a C++17 compiler shouldn't be a huge problem for our downstream. Why not go further? C++20 support would require gcc 10 or 11, and while we could go that far it seems like we should be conservative by default.
See discussion on #106 Full C++17 support came in gcc 8 (although most of it was present in gcc 7 already. In terms of our likely target platforms already ship that: * Debian oldstable shipped with gcc-10. * The oldest supported Yocto release is Dunfell, which shipped gcc 9.5 That suggests that getting a C++17 compiler shouldn't be a huge problem for our downstream. Why not go further? C++20 support would require gcc 10 or 11, and while we could go that far it seems like we should be conservative by default.
Fixed! |
At the moment Aktualizr requires C++11 to build. I propose we bump that to C++17.
Full C++17 support came in gcc 8 (although most of it was present in gcc 7 already. In terms of our likely target platforms already ship that:
That suggests that getting a C++17 compiler shouldn't be a huge problem for our downstream.
Why not go further? C++20 support would require gcc 10 or 11, and while we could go that far it seems like we should be conservative by default.
Comments welcome!
The text was updated successfully, but these errors were encountered: