Migrate to C++17

[oleg-derevenetz]

Hi @ihhub @idshibanov @zenseii what do you think about migrating to C++17? Sometimes features from it would be useful. For example, when I write code like this:

fheroes2/src/fheroes2/ai/normal/ai_normal_kingdom.cpp

Lines 97 to 107 in d94c531

	const auto heroesToIgnore = std::make_pair( world.GetHeroesCondWins(), world.GetHeroesCondLoss() );
	Heroes * firstRecruit = rec.GetHero1();
	if ( firstRecruit == heroesToIgnore.first || firstRecruit == heroesToIgnore.second ) {
	firstRecruit = nullptr;
	}
	Heroes * secondRecruit = rec.GetHero2();
	if ( secondRecruit == heroesToIgnore.first || secondRecruit == heroesToIgnore.second ) {
	secondRecruit = nullptr;
	}

I'm always afraid to mix something up - firstRecruit with secondRecruit or .first with .second. With C++17 I would write like this:

auto ignoreRecruit = [&heroesToIgnore]( const Heroes * recruit ) {
  return std::apply( [recruit]( auto... hero ){ return ( ( recruit == hero ) || ... ); }, heroesToIgnore );
};

if ( ignoreRecruit( firstRecruit ) ) {
  [...]
}
if ( ignoreRecruit( secondRecruit ) ) {
  [...]
}

Much less error-prone, no chance to mix something up at all, but the same efficiency due to the local templated lambda which will be inlined.

[ihhub]

Hi @oleg-derevenetz , there are few reasons why didn't move to C++17 in the past:

• moving in stages. The original code base was on C++03. It took a lot of time to move to C++11 and polish the code to use the full power of it. So moving to C++14 and then to C++17 would be less painful.
• support of old platforms. For example, Visual Studio 2015 which can be used to compile the project even for Win XP, does not support the whole spectrum of C++17 features

I think the first point is not relevant anymore and our code is in a (relatively) pretty good shape with C++11. The second point requires an analysis how many and which platforms we are going to drop to support.

Overall, there are no big barriers to move C++17 now.

[oleg-derevenetz]

Hi @ihhub Yeah, it looks like we will need to drop the VS2015 support. On the other hand, we use VS2019 in our CI anyway, and, according to this table, VS2017 supports the C++17 just fine and it can build for WinXP, so we can replace VS2015 project files by VS2017 project files and still have target audience on WinXP (but they will need to build the project themselves, just like now).

Regarding other platforms, GCC has C++17 from GCC 7 onwards (was released in 2017) and Clang has the full support of core C++17 features from Clang 6 onwards (was released in 2018), so it shouldn't be a problem on Linux or relatively modern versions of macOS. It looks like Switch and PSV toolsets use the modern GCC as well.

[zenseii]

If this only brings with it benefits then why not. My only question is whether this means I have to avoid writing code in a specific way or change the old code in a certain way whenever I'm working on it.

[oleg-derevenetz]

@zenseii

My only question is whether this means I have to avoid writing code in a specific way or change the old code in a certain way whenever I'm working on it.

No, it doesn't mean this :) A number of new features will be available, but there is no need to necessarily use them.

[ihhub]

We moved to C++17 so I am locking this discussion.