ihhub
Improvement: use c++20 standard when compiling
This PR changes from c++17 to c++20 when compiling C++20 has many features that simplify C++ and short make code shorter and clearer.
Possible disadvantages: Compilers guarantee to be C++17 complete, which isn't true to C++20. That being said, it takes many years for the vendor to officially declare a standard as feature-complete. While not 100%, most compilers have pretty good coverage for c++20 by now.
Hi @usidedown ,
What exact features C++20 standard offers that we must use to significantly simplify the development? Keep in mind that we support many platforms and not all of them have up to date compilers. Unless, C++20 offers something extremely good and valuable I see no reason to switch to a higher version just for the sake of using a newer standard. Additionally, higher C++ standard means higher barrier for any non-C++ people to contribute to the project.
Hi @usidedown ,
What exact features C++20 standard offers that we must use to significantly simplify the development?
I wouldn't say must 😄. Of course everything is optional. Here are however few good features:
Concept (language feature) - This greatly simplifies template code and replaces weird paradigms such as SFINAE. E.g.
template <typename T, std::enable_if_t<std::is_integral_v<T>, bool> = true>
std::string GetHexString( const T value, const int width = 8 )
{
/*...*/
}
to
std::string GetHexString(std::integral auto value, const int width = 8)
{
/*...*/
}
std::ranges (library feature) - simplifies iterator code Basically any iterator pair begin,end can be replaced with a single range.
std::span (librarhy feature) - like std::string_view but for non-string data
uint32_t calculateCRC32(const uint8_t* data, const size_t length);
to
uint32_t calculateCRC32(std::span<const uint8_t> data);
std::format (library feature)
std::ostringstream oss;
oss << "Value: " << value << " Name: " << name;
std::string s = oss.str();
to
std::string s = std::format("Value: {} Name: {}", value, name);
There are other small compiler features such as constexpr/consteval improvements, struct designated initializers, etc.. And also other small library improvements.
Keep in mind that we support many platforms and not all of them have up to date compilers.
That's why I believe c++20 strikes a good balance between features and compiler support. Build passes on all platforms after the change to c++20 as far as I can tell.
Additionally, higher C++ standard means higher barrier for any non-C++ people to contribute to the project.
C++ in general is a complex language that's not beginner friendly. Newer standards however bring simplifications and improvements to safety, some of which listed above. IMHO these lower the barrier of entry, not raise them.
We have quite a few templates (where SFINAE is currently used and where concepts would be useful) compared to the total amount of code. Yes, ranges, std::span, std::format are funny features, but I'm not sure if they're worth the 1.5-2x compilation slowdown and potential compilation problems on older Linux and macOS distributions. On the master branch, typical MSVC workflow's compilation stage takes ~2.5 minutes to complete, with this PR it's about ~4.5 minutes. Linux-based workflows also has build time difference about 1 - 1.5 minutes (that's a lot considering the total build time of 2 - 2.5 minutes for the master branch). On the master branch, the Clang Analyzer workflow fits in 30 minutes (with CTU enabled!) while for this PR it just fails because 1 hour is no longer enough for it to complete. Compiler developers first need to speed up the compilation process. The fact that the compiler compiles or analyzes 1.5-2 times slower simply because we applied a different standard (without any changes to the compiled code itself!) looks no good.
Okay, the compile time issue is real. I'm closing this as trying to shorten compile time is out of scope.