* fix: validate multipleOf fails on float-point value
* make clang-tidy happy.
* fix test case error when multipleOf is float but number is int
* fix multiple of float number
A recent fix to discard patch from invalid logical combination
introduced a lot (for large json instance and/or schema) of copies to
make a patch backup. On some case, this introduced up to a 100x slower
validation time.
Resizing the patch object to its previous size avoid unnecessary
temporary allocations from the backup object.
* Remove travis file
* Apply pre-commit fixes
* Modernize cmake file
- Added JSON_VALIDATOR_SHARED_LIBS to properly handle shared-library
- Bumped minimum cmake to 3.11 to use no-source add_library
- Bumped minimum cmake to 3.14 to properly support FetchContent (FetchContent_MakeAvailable)
- Converted Hunter package manager to FetchContent (It is plenty mature these days)
- Added namespace to exported target
- Made the cmake file compatible with FetchContent
* Use simplified FetchContent CI
* Add simple status messages
* Handle nlohmann dependency
Not an ideal approach, but required in order for the exported target to have appropriate linkage.
Maybe this can be designed to become a PRIVATE link library, but then how does it ensure the target is installed?
* Remove CMake-install test
This will be moved to packaging integration tests
* Enable code coverage
* Reconfigure ci presets
Signed-off-by: Cristian Le <cristian.le@mpsd.mpg.de>
The code assumes that char is signed, but whether char is signed or
unsigned is implementation defined. On some architectures like PowerPC,
GCC treats char as unsigned resulting in compile errors:
smtp-address-validator.cpp:213:1: error: narrowing conversion of '-32' from 'int' to 'char' [-Wnarrowing]
Fix this by specifying signed char.
Default-values on schemas with a $ref field are now stored within
a new reference schema which links to the original reference schema.
It contains the default value and keeps a strong reference (shared_ptr)
to the original reference.
Fixes#209
* Use explicit type conversion
As detailed in https://github.com/nlohmann/json#implicit-conversions, it's recommended not to use implicit conversions from json. This change allows those using "JSON_ImplicitConversions" OFF to still build this package.
* Use matching type from declaration for some variables.
