/data/mwrep/res/osp/RapidJson/20-0-0-0/include/rapidjson/document.h:729:58: error: use of overloaded operator '!=' is ambiguous (with operand types 'rapidjson::GenericValue<rapidjson::UTF8<char>, rapidjson::MemoryPoolAllocator<rapidjson::CrtAllocator> >::MemberIterator' (aka 'rapidjson::GenericMemberIterator<false, rapidjson::UTF8<char>, rapidjson::MemoryPoolAllocator<rapidjson::CrtAllocator> >') and 'rapidjson::GenericValue<rapidjson::UTF8<char>, rapidjson::MemoryPoolAllocator<rapidjson::CrtAllocator> >::MemberIterator')
for (MemberIterator m = MemberBegin(); m != MemberEnd(); ++m)
RAPIDJSON_CLZLL is defined as macro of __builtin_clzll when
using gcc to compile. This introduces two issues:
1. in gcc __builtin_clzll returns int, not uint32_t.
2. __builtin_clzll return is undefined when input x is 0
See: https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html
This patch removes RAPIDJSON_CLZLL, merges __builtin_clzll to
internal clzll with input check and return value explicit cast.
Change-Id: Iac4b355dc5e5b4ed9b3f35a640b6b5537e76f22c
Signed-off-by: Jun He <jun.he@arm.com>
Co-authored-by: Jun He <jun.he@arm.com>
This change comes up with compile time pre-processor directives to
tune the behavior of rapidjson wrt memory consumption. The idea is to
allow each module using this library to choose the right defaults based
on how it consumes memory and what performance it expects.
1. RAPIDJSON_DEFAULT_ALLOCATOR: If defined allows you to choose
CrtAllocator over MemoryPoolAllocator. If it is not defined, chooses MemoryPoolAllocator by default.
2. RAPIDJSON_DEFAULT_STACK_ALLOCATOR: If defined allows you to choose
MemoryPoolAllocator over CrtAllocator. If it is not defined, chooses CrtAllocator by default.
3. RAPIDJSON_VALUE_DEFAULT_OBJECT_CAPACITY and RAPIDJSON_VALUE_DEFAULT_ARRAY_CAPACITY: If defined and set to a
value, uses that value for default number of objects/array elements to be pre-allocated. If not defined,
uses value of 16: the current default.
Verified that all tests pass.
clang warns about throwing from RAPIDJSON_NOEXCEPT_ASSERT() in a nothrow
context.
If RAPIDJSON_ASSERT() throws it can never be used for _NOEXCEPT_ASSERT(),
so use C assert() instead.
Finally (and originally), since RAPIDJSON_ASSERT() in "unittest.h" throws,
make it define RAPIDJSON_ASSERT_THROWS for RAPIDJSON_NOEXCEPT_ASSERT() to
now do the right thing.
The Pointer passed to construct the Schema can be from the stack or any
transient storage, so the copy stored in the Schema must have the same
lifetime/allocator as the Schema itself.
Speed is more important than alphabetical order (which makes few sense in
JSON in general, and with pointers especially). The use case is indexing
in std containers, i.e. O(log n) with rbtree, so the faster comparison
the better.
I must be too dumb to understand the mess MSVC (32bit only) did with the
previous loop, and to figure out how it might have make it never end.
Anyway, hopefully any compiler can grok this new loop...
