Sometimes, particularly when Microsoft's windows.h is included, min/max
are defined as macros, interfering with use of
std::numeric_limits::min() and the like.
To guard against this, the function name is wrapped in an extra set of
parenthesis, which inhibits function-style macro expansion.
* Safely assert upon passing NULL string without length
(requires usage of RAPIDJSON_ASSERT within an expression)
* Allow using a NULL string together with an explicit length 0
(GenericStringRef, GenericValue::SetString, ...), see #817
* Add GenericValue::SetString(StringRefType, Allocator&) overload
* Add tests for the various cases
As reported by @Llerd in #962, the `copyConstStrings` parameter
has not been forwarded recursively to the constructors of
object members and array elements.
Copying the result of an in-situ parsing into another value/document
currently requires that the original buffer - still holding the strings
from the parsing, outlives the destination object as well.
In order to obtain a "full" copy of a GenericValue, this commit adds
an optional flag `copyConstStrings` to `CopyFrom`, which then forces
to take a copy of all embedded strings in the source value.
This solves the problem discussed in #962.
also use internal::StrLen to get the string lengtht,
when it call FindMember(StringRef(name)).
Now use GenericValue construct it, then can use the std::string.size.
now it will be faster.
UBSAN gave in Value.IsLosslessFloat:
include/rapidjson/document.h:981:38: runtime error: value 3.40282e+38 is outside the range of representable values of type 'float'
note that std::numeric_limits<uint64_t>::max() and
std::numeric_limits<int64_t>::max() aren't exactly representable in a
double, so we need to be strictly less to be definitely lossless
UBSAN gave during Value.IsLosslessDouble test:
include/rapidjson/document.h:955:42: runtime error: value 1.84467e+19 is outside the range of representable values of type 'unsigned long'
