Bump minimum C++ standard to 17

[hobu]

As titled, this bumps our floor to C++17. It is proposed to implement this for GEOS 3.14+, not GEOS 3.13, which is expected soon.

The C++11 RFC has this comment:

Is there a plan to upgrade to C++14 or C++17 to allow use of the C++ latest features? No, there is no plan. It is, however, recognized, such motion may be put to the vote around 2020.

I think that given we are near the end of 2024, it's time to finally increment. I don't think it requires an RFC due to us lagging the increment of many other projects and compilers on the systems that GEOS is used on. It was the C++11 increment that was disruptive and C++17 is not expected to be this late in the cycle.

[pramsey]

What are the c++17 features we're dying to get our hot little hands on?

[rouault]

What are the c++17 features we're dying to get our hot little hands on?

Actually a C++14 feature:

std::unique_ptr<CoordinateSequence> linePts(new CoordinateSequence());

==>

auto linePts = std::make_unique<CoordinateSequence>();

The fact that CI passes without any change shows that this is a no-brainer change

[dbaston]

What are the c++17 features we're dying to get our hot little hands on?

Some things I use:

• if constexpr (lets you avoid template boilerplate)
• structured bindings ( for( const auto& [key, value] : map) )
• std::optional, to avoid signatures like bool mayybeGetDouble(double& d)
• inline member variables, lets you avoid initializing static member variables outside of the class definition
• std::variant and std::any
• std::string_view

I haven't used them, but parallel STL algorithms may be useful for GEOS.

[pramsey]

OK with this, obvs wait until 3.13 is branched before merging.

[dbaston]

Are we ready to merge this? Just found myself reaching for an if constexpr and it wasn't there...

[pramsey]

Are we ready to merge this? Just found myself reaching for an if constexpr and it wasn't there...

Yes