This repository was archived by the owner on Mar 22, 2023. It is now read-only.
Repository navigation
This repository was archived by the owner on Mar 22, 2023. It is now read-only.
Move on to a new C++ standard (14) #1190
Description
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>
Activity
igchor commentedon Aug 4, 2021
We just need to see what compilers are supported in RHEL/CentOS
KFilipek commentedon Aug 4, 2021
From my investigation there are gcc 8.x releases available:
igchor commentedon Aug 4, 2021
I think that In that case we could even think about switching to C++17
seghcder commentedon Apr 6, 2022
Would it be possible to perhaps have two levels -
lukaszstolarczuk commentedon Apr 6, 2022
@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 commentedon Apr 6, 2022
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 commentedon Apr 6, 2022
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 commentedon Apr 7, 2022
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 commentedon Apr 7, 2022
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 ...
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 commentedon Apr 7, 2022
Thanks for all the info!
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 commentedon Apr 7, 2022
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 :-)
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...