[Feat] Upgrade C++ standard support to C++17

[nilason]

Moving forward, it will be increasingly difficult to keep the C++ standard support of C++11. The required dependency GDAL 3.9+ (released in May 2024) and the important PDAL 2.4+ (released in Mars 2022) for example, are supporting C++17.

I propose to upgrade our C++ standard support to C++17: our code builds without changes in C++17 "mode", it will probably in first instance be a question of declaring our intention.

C++17 summary

[echoix]

Also see #3846

[veroandreo]

We kinda already updated them de facto by removing older standards from CI build tests in #3846.

The next PSC meeting is on Aug 9th, I'll put this in the agenda. Now, do we really need a new RFC with a justification or can we just vote on updating the standards in the last section of the existing one?

[nilason]

Just want to clarify, we may keep the C++11 standard support as there are no urgent code changes planned (requiring C++17) or we do not hook up (if I'm not mistaken) GDAL C++ API (only C). Building GRASS GIS with PDAL support however, requires setting C++17 standard support. It is another question, how we set up the CI runners.

The next PSC meeting is on Aug 9th, I'll put this in the agenda. Now, do we really need a new RFC with a justification or can we just vote on updating the standards in the last section of the existing one?

I think a new RFC needs to be approved, which supersedes the current (cf. e.g. Python's https://peps.python.org/pep-0001/). (The RFC files should probably be prepended with the RFC number.)

[veroandreo]

Just want to clarify, we may keep the C++11 standard support as there are no urgent code changes planned (requiring C++17) or we do not hook up (if I'm not mistaken) GDAL C++ API (only C). Building GRASS GIS with PDAL support however, requires setting C++17 standard support. It is another question, how we set up the CI runners.

The next PSC meeting is on Aug 9th, I'll put this in the agenda. Now, do we really need a new RFC with a justification or can we just vote on updating the standards in the last section of the existing one?

I think a new RFC needs to be approved, which supersedes the current (cf. e.g. Python's https://peps.python.org/pep-0001/). (The RFC files should probably be prepended with the RFC number.)

Would you be willing to draft a new one then?

For the Python version support, the RFC states a rule to update the minimum version supported so we don't need to write a new RFC every time. Isn't there a way to do the same for C and C++? (Apologies if this is a silly question!)

[nilason]

I think a new RFC needs to be approved, which supersedes the current (cf. e.g. Python's https://peps.python.org/pep-0001/). (The RFC files should probably be prepended with the RFC number.)

Would you be willing to draft a new one then?

Sure, I will.

For the Python version support, the RFC states a rule to update the minimum version supported so we don't need to write a new RFC every time. Isn't there a way to do the same for C and C++? (Apologies if this is a silly question!)

Python has a predictable release schedule with a new release (and importantly an end-of-life version) every year. That makes it possible to follow on our side as per RFC 8. C/C++ standard is quite a different issue and I see no obvious way to "automate" this.

[veroandreo]

I think a new RFC needs to be approved, which supersedes the current (cf. e.g. Python's https://peps.python.org/pep-0001/). (The RFC files should probably be prepended with the RFC number.)

Would you be willing to draft a new one then?

Sure, I will.

Thanks!! 🙏