path handling and c++17

[JRStolle]

I was wondering if it would be a good idea to enable c++17 features -> set required version in cmake to c++17?
The reason is that the path file system handling would be much easier, since I had some problems getting the relative path to work in Windows for relative references ($ref) .
If that is an option, I could try to do a pull request.
Thanks for feedback.
Jan

[LecrisUT]

This might require specific implementation on the code side to take advantage of it, but for the build side it can be something like:

# Check C++ standard support
if (cxx_std_17 IN_LIST CMAKE_CXX_COMPILE_FEATURES)
  set(default_cxx_std 17)
else ()
  set(default_cxx_std 11)
endif ()
# Expose C++ standard to the user to overwrite
set(JSON_VALIDATOR_CXX_STD ${default_cxx_std} CACHE STRING "JsonValidator: C++ standard to use")
...
# Important to be local variable and not a cashe
set(CMAKE_CXX_STANDARD ${JSON_VALIDATOR_CXX_STD})

[JRStolle]

In that case, if the cxx standard could be overwritten or set to something below c++17 then the includes would not be found and the project would not compile.

[LecrisUT]

That is not that bad because everything can be #ifdef guarded around what the compiler was requested to support. I have had mixed experience with these, but for something like C++17, I think the macros are well defined that it would not be that bad.

The question is if it makes sense to migrate completely to C++17. I personally think it's a good transition to do, but it's ultimately the choice of who can contribute and maintain these changes. I am definitely split on time this year and/or I can find a permanent work position, but after that I do plan to clean up all of the build situation and make these stuff much easier to maintain.

PS: please reply in the discussion thread next time

[JRStolle]

Yes, time is always an issue and usage of #ifdefs is usually frowned upon. I will check if I can get the local $refs to work, then I would have some more insight on what would be needed at least. I thought $ref some_sub_schema.json should call the sub_schema.json in the same directory as the root. I did not see this in the issue list though, so chances are I am using it wrong.