Repository navigation
Update to C++20? #107
Description
This would notably allow:
| Feature | Benefit |
|---|---|
std::u8string |
Clearer UTF-8 string semantics |
std::format |
dropping the dependency on fmt |
std::span<T> |
An alternative to const std::vector<T>& that avoids having to construct a vector if you've got another compatible sequence - not sure if this is a problem outside of test code |
<=> operators and default comparison operators |
Reduce code needed to define comparison operators |
| Ranges | Simplifies using std algorithms, I don't think there's anything major in libloot that would benefit from using the new functionality though |
std::string_view::starts_with(), std::string_view::ends_with() |
Trivially replace usage of a couple of Boost functions (still need the string algorithms library for many other uses) |
| Concepts | Better templates - not really significant for libloot, it doesn't define many templated types or functions |
There might also be some other stuff I've missed - modules is intentionally omitted due to poor support outside of MSVC.
Updating to C++20 may mean increasing the compiler version requirements. It looks like MSVC 2019 and GCC 13.1 should be enough. From a CI perspective, no changes would be needed:
- libloot and LOOT have used MSVC 2019 in CI since February 2022, shortly before GitHub removed its runners that provided MSVC 2017, so 2019 might already be required in practice.
- libloot and LOOT have used GCC 13 in CI since migrating from the Ubuntu 20.04 runners to 24.04 runners in January 2025. Before that it was using GCC 10.
There's not really a compelling reason that I've seen to update to C++20, but it is now 5 years old and the required compilers are at least just under 2 years old, so updating the build requirements doesn't seem unreasonable and there might be language-level improvements that lead to less obvious things like performance improvements.
That said, I did just flip the switch in CMake and immediately ran into compiler errors due to std::filesystem::path::u8string() now returning a std::u8string instead of a std::string, and astoundingly there doesn't seem to be an easy way (barring a pointer reinterpret cast) to convert a std::u8string to a std::string even though it should be trivial (I could understand it if the other way around required a UTF-8 validity check). That alone is enough for me to think it's not worth dealing with.
Activity
Ortham commentedon Apr 29, 2025
On the subject of compiler versions, GitHub Actions is removing its windows-2019 images by the end of June, so that's forcing an update to MSVC 2022 anyway.
Ortham commentedon Jun 12, 2025
With the switch to a mostly Rust codebase in fa193c1, the benefits of updating to C++20 are reduced, but it's also easier as there's less code to update:
std::u8stringstd::span<T>const std::vector<T>&that avoids having to construct a vector if you've got another compatible sequence - not sure if this is a problem outside of test code<=>operators and default comparison operatorsHowever, making these changes would only be worthwhile if they're present in the public API, which would force libloot's consumers to use C++20 or higher, and the inflicting the pain of using
std::u8string(which is unavoidable even if not used directly, thanks tostd::filesystem::path::u8string()) doesn't seem worth it.