EasyRPG
Upgrade to C++17
Here is table of platform support. Once all platforms are on C++17 enabled compilers we can upgrade.
| Platform | Compiler Version | C++17 Enabled |
|---|---|---|
| Windows | MSVC 19.x | ✔️ |
| Linux / emscripten / libretro | gcc 9 | ✔️ |
| Mac OSX / BSD | clang 9 | ✔️ |
| devkitPro (Wii, 3ds, switch) | gcc 10 | ✔️ |
| PSP | gcc 9.3.0 | ✔️ |
| PS Vita | gcc 9.1.0 | ✔️ |
| MorphOS | gcc9 | ✔️ |
| AmigaOS4 | gcc8 | ✔️ |
| BeOS (Haiku) | gcc7 | ✔️ |
| AROS ABIv0 | gcc6 | ❌ |
| GCW Zero | gcc4.9 | ❌ |
It's been a year and I'd like to revisit this.
It looks like GCW Zero has experiment support for gcc6 https://boards.dingoonity.org/gcw-development/gcw-zero-toolchain-for-windows-(cygwin)-2013-10-04/
This post was from 4 years ago. It seems likely this platform will remain stagnant forever. How long do we want to be held back by this one for new player development?
https://github.com/aros-development-team/AROS
AROS is still on gcc 6 but they have experimental gcc 9 and 10 for x86_64. Do we support all the hardware platforms on AROS?
How about after the next release? This will be in maybe 2-3 months? Why after the next: This way everyone can profit from the significant improvements we did over the last year. (Events, battle, midi, translation etc...)
There is really no real movement anymore here. So gcc7 as the new low bar is fine to me.
Other opinions?
But I will not accept any new C++17 library features that interact with the underlying system. e.g. std::filesystem. We always have bad experiences with broken newlib implementations.
gcc <filesystem> support comes with gcc8, so it is not pretty usable yet (there's <experimental/filesystem> with gcc7 but as the name says, it's experimental, so...).
Current limitation is Haiku with gcc 7.
The c++17 support for other things looks sane, so +1 for the c++17 bump.
I already removed the jenkins jobs for gcw0 a few days ago. If there ever is a new toolchain, we can always add them back. So gcc7 is ok from me. And it should come this year.
okay then this is decided for "After the next release". Also "After all big PRs are in" because the StringView -> std::string_view change will be otherwise mess. ;)
Where's the source of gcc7 requirement for Haiku? It seems there is some gcc8 on Haiku since 2018-2019. If that's correct, we could bump to gcc8 sooner.
I think MorphOS and AmigaOS4 have up to date compilers with C++17 support, so there shouldn't be an issue there. AROS ABIv0 is unfortunately stuck with GCC6 and ABIv1 x86_64 is still not that stable, so it's a moving target. If AROS is the only platform blocking the C++17 transition, then it's probably the best to drop it until the ABIv1 branch is mature enough.
That discussion was more than 2 years ago so imo the baseline can shift again. In that table most compilers were already at gcc9 so they likely use gcc10 by now.
We could use a subset (!) of C++20 by targeting g++10. This adds support for std::span and std::string_view::(starts|ends)_with, allowing to remove some helpers we have.
@fdelapena If there are no objections I would increase this to C++17 now for liblcf and Player.
There is no code really needing it right now, is just a "because we can"