Refactored the iterative parser so that users can parse a single JSON
element at a time (invoking the handler one time) and then return
control to the calling code. Call IterativeParseInit to start, and then
call IterativeParseNext to retrieve one JSON element. Use
IterativeParseComplete to check for JSON document completion.
Older GCC versions fail compiling RapidJSON due to a warning
include/rapidjson/reader.h:578: error: suggest a space before ';' or explicit braces around empty body in 'while' statement
: warnings being treated as errors
From the Debian wiki: https://wiki.debian.org/X32Port
X32 is an ABI for amd64/x86_64 CPUs using 32-bit integers, longs
and pointers. The idea is to combine the smaller memory and cache
footprint from 32-bit data types with the larger register set of
x86_64. The 64-bit registers can make computation more efficient,
and with 8 additional registers available, there is less pressure
compared to i386/i686.
rapidjson makes an incorrect assumption in a check for 64 bit
platforms, and uses __LP64__ exclusively. This fix adds an
additional check for __x86_64__ && __ILP32__ defines, as a very
conservative fix. However, the usage of __LP64__ would be a problem
for other "mixed" applications like ARM ILP32, so a better detection
scheme might be needed in the future.
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.
Prior to this change, a user could incorrectly pass a Document object to
SchemaValidator. This would implicitly construct a SchemaDocument, which
would then be destructed before the validator was used. This caused
unpredictable results including memory corruption and program crashes.
Fix inconsistent calling of template functions in PutN in stream.h. When
used with a GenericStringBuffer<<UTF8>, MemoryPoolAllocator>, PutN would call
PutReserve from stream.h, and PutUnsafe from stringbuffer.h. This
resulted in bytes being added to the buffer without allocating space.
This was not an issue when used with the default memory allocator,
because in this case the specialized PutN is used from stringbuffer.h.
