On MSVC compiler, temporaries that are constructed during a
list initialization, are sometimes destroyed even before calling
the initializing constructor, instead of at the end of the
containing full-expression. This is clearly non-conforming to
[class.temporary].
As the impact of this bug is silently producing incorrect
JSON values, move eagerly from rvalues to be safe.
See https://stackoverflow.com/questions/24586411
- You can now pass a reference to a vector to the to_cbor and to_msgpack functions. The output will be written (appended) to the vector. #476
- You can now pass an output stream with uint8_t character type to the to_cbor and to_msgpack functions. #477
- You can now read from uint8_t */size in the to_cbor and to_msgpack functions. An input adapter will be created from this pair, so you need to use braces. #478
This commit works around an issue in std::initializer_list design.
By using a detail::json_ref proxy with a mutable value inside,
rvalue-ness of an input to list initializer is remembered and
used later to move from the proxy instead of copying.
Travis found an error with Clang 3.8's sanitizers, see https://travis-ci.org/nlohmann/json/jobs/256366699. Unfortunately, I cannot reproduce this error with clang version 6.0.0 (trunk 308825) locally. However, this seems to be an issue, because so far, we did not reset a value after moving from it.
A complete rewrite of the string escape function. It now provides codepoint-to-\uxxxx escaping. Invalid UTF-8 byte sequences are not escaped, but copied as-is. I haven’t spent much time optimizing the code - but the library now agrees with Python on every single Unicode character’s escaping (see file test/data/json_nlohmann_tests/all_unicode_ascii.json).
Other minor changes: replaced "size_t" by "std::size_t"
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.
These breaks were just added to silence a GCC warning - the GCC is right about warning as it cannot know that the expect function will not return in these two scenarios.
