is_compatible_* traits were used in from_json, but it made no sense
whatsoever.
It used to work because of non-SFINAE correctness + json_ref
unconstrained variadic template constructor.
SFINAE checks are becoming quite complex, we need a specification of
some sort describing:
* which concepts the library uses
* how the conversion to/from json works in detail
Having such a specification would really help simplifying the current
code (as well as having meaningful checks).
Fixes!1299
Beside the fix discussed in #961, we also had to re-adjust a test case. It seems that it was failing before, and I "fixed" it to work with the broken implementation...
- updated documentation wrt. new repository layout
- temporarily switched off Homebrew --HEAD building (can only be switched on after release)
- set copyright date to 2018
* Rename 'develop' folder to 'include/nlohmann'
* Rename 'src' folder to 'single_include/nlohmann'
* Use <nlohmann/*> headers in sources and tests
* Change amalgamate config file
- Implemented "copy" in terms of "add".
- Added check for JSON Pointer array indices to make sure the complete reference token was processed.
- Added test suite from https://github.com/json-patch/json-patch-tests
We had a lot of issues with failing roundtrips (i.e., parse errors from serializations) in case string were stored in the library that were not UTF-8 encoded. This PR adds an exception in this case.
The CBOR and MessagePack parsers now expect the input to be read until the end. Unless the new parameter "strict" is set to false (it is true by default), an exception is raised if the parser ends prematurely. This is a breaking change as the parsers ignored unread input so far.
Furthermore, the offset/startIndex paramter introduced in #462 was removed as this behavior can be mimicked with an iterator range. For instance, instead of calling "from_cbor(vec, 5);", you can write "from_cbor({vec.begin()+5, vec.end()});".
It makes no sense to have this special exception. Instead of throwing when an input adapter is created, it is better to detect a parse error in later usage when an EOF is "read" unexpectedly.
