You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently we use char[]s of PETSC_MAX_PATH_LEN with a suite of hand-rolled tools in utils.h for dealing with paths and determining existence of files. This functionality is in std::filesystem, and in a mostly-compliant C++11-compatible header-only library here.
If we move our C++ standard up to 17 (#55), this functionality is present in std::filesystem which is easier to include as opposed to the third party lib that is linked. What are thoughts on changing the standard?
Updating to C++17 is preferred to keeping an extra dependency imho. Probably more testing is needed than just building a couple of different ExaGO configurations. I am not sure either is needed, though. All we need here are some very standard string manipulations.
The text was updated successfully, but these errors were encountered:
Currently we use char[]s of PETSC_MAX_PATH_LEN with a suite of hand-rolled tools in utils.h for dealing with paths and determining existence of files. This functionality is in std::filesystem, and in a mostly-compliant C++11-compatible header-only library here.
If we move our C++ standard up to 17 (#55), this functionality is present in std::filesystem which is easier to include as opposed to the third party lib that is linked. What are thoughts on changing the standard?
From @pelesh
The text was updated successfully, but these errors were encountered: