Move on to a new C++ standard (14)

[lukaszstolarczuk]

Rationale

C++14 is now commonly implemented within compilers, so we should consider using it by default, to take advantage of new features.

Description

Update CMake files, readme files, and our implementations to make use of new features.

API Changes

Rather none.

Implementation details

There are at least few places that could use this update, e.g.:

• get rid of our implementation of integer/index_sequence (link)
• <TBD>

[igchor]

We just need to see what compilers are supported in RHEL/CentOS

[KFilipek]

From my investigation there are gcc 8.x releases available:

OS	gcc ver
CentOS 8.4.2105	gcc 8.4.1-1
RHEL 8	gcc 8.2.1

[igchor]

I think that In that case we could even think about switching to C++17

[seghcder]

Would it be possible to perhaps have two levels -

• Start using/supporting C++14/17 in the library code
• Validate on C++20/OneTBB-latest/hwloc-latest as part of CI? Also to get early warnings of any upcoming issues...

[lukaszstolarczuk]

@seghcder, as for testing in CI we do check various C++ standards -
https://github.com/pmem/libpmemobj-cpp/blob/master/utils/docker/run-build.sh#L216

is it important for you to validate on latest OneTBB?

[seghcder]

ok, thanks re C++20.

Re tbb - no, but I'd probably align with the latest version that has been tested. I see you are using tbb-devel in the Fedora 34 build, which puts it at tbb-2020.3. I know there are some deprecated functions in my own code I need to address soon.

I think also you are only directly using tbb-devel for testing? I thought originally that the concurrent hash map container optionally used tbb, but all I can see now are the comments referring to tbb.

BTW, I've learnt a lot from your build chain!

[seghcder]

I think that In that case we could even think about switching to C++17

Another benefit of C++17 is tbb is embedded in the standard, which might help simplify or extend concurrency support in libpmemobj-cpp?

How far forward you support also depends on how much legacy you need to support with the team you have. What's your policy re how far back you need to support? I think there are already kernel limitations re pmem support below 4.2 and older OS versions rely on patching, so one option might be to start supporting only those OS versions with out of the box supported kernels.

One option would be to support OS versions N and N-1. With RHEL9 due out maybe next month, then RHEL7 and associated variants might go out of your support range?

[igchor]

TBB is only used in concurrent hash map tests (e.g. here to verify if hash map can support different mutexes (so, in a very limited way). Apart from that, there is no dependency on tbb I believe.

Are you referring to C++17 support for parallel_policy? I'm not sure if we have any places in code where we could use that. For sure, it might be useful for the user of libpmemobj-cpp (e.g. to process data in pmem::obj::vector), but this does not require any changes in libpmemobj-cpp (it should work with C++17 right now).

As for OSes: we do require kernel with PMEM support. We also maintain libpmemobj-cpp versions which are present in the latest LTS OSes. Here, you can find list of those versions: https://pmem.io/libpmemobj-cpp/

[seghcder]

All good. Understood re parallel_policy - yes we've used that in some areas.

My comment about moving on from RHEL7 / CentOS was more to do with your comment above ...

We just need to see what compilers are supported in RHEL/CentOS

If a limitation to move to C++14/17(/20) was RHEL7/CentOS7, then it might be ok to deprecate support for those? RHEL8 has GCC11 as an optional package, and GCC11 has started implementing some C++23 proposals :-)

[lukaszstolarczuk]

Thanks for all the info!

We just need to see what compilers are supported in RHEL/CentOS

I think Igor's comment mentioned RHEL/CentOS because they always "lagged" the most with compilers/packages updates... but since you're saying RHEL9 is coming shortly we may finally consider (somehow) planning it.

The question is (as usual) how important is that for you, @seghcder ? 😉 and perhaps, which min. C++ standard would you consider the best?

[seghcder]

The question is (as usual) how important is that for you, @seghcder

My main thinking is how to minimise legacy work for the pmdk team so they can focus on new features and enhancing the library with the new functionality in the later C++ versions :-)

which min. C++ standard would you consider the best?

It's probably not my call as a single user ... we've moved to Fedora 35 and C++20 for development, and plan to host on RHEL8.5.. but there may be customers who need support for older toolchains. If it was my call, I'd probably say C++17 min and starting to add optional C++20 support eg for concepts. And modules are here...