d87b698d0f made all definitions of GenericMemberIterator consistent as
classes (they were structs with RAPIDJSON_NOMEMBERITERATORCLASS
defined), but it didn't keep the member definitions public.
document.h:586:71: error: 'Iterator' is a private member of
'rapidjson::GenericMemberIterator<false, rapidjson::UTF8<char>, rapidjson::MemoryPoolAllocator<rapidjson::CrtAllocator> >'
typedef typename GenericMemberIterator<false,Encoding,Allocator>::Iterator MemberIterator; //!< Member iterator for i...
^
document.h:2124:32: note: in instantiation of template class
'rapidjson::GenericValue<rapidjson::UTF8<char>, rapidjson::MemoryPoolAllocator<rapidjson::CrtAllocator> >' requested here
class GenericDocument : public GenericValue<Encoding, Allocator> {
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...
On (my) linux, perftest reports:
- ~40% gain for FileReadStream (Take() loop),
- ~10% gain for ReaderParse_DummyHandler_FileReadStream.
With the same logic applied to BasicIStreamWrapper, which thus can now
also be created with a user buffer, performances align with those of
FileReadStream (same buffer size).
The "unbuffered" versions (added for FileReadStream) work solely with
the internal peekBuffer (Ch[4]) and are measured in perftest. When
performances don't matter much, they can avoid the use of large
stack/heap buffers.
Because `isPeek()` is side effect free this should not change anything.
The reason this warning is not shown in the unit tests is because the asserts
are always evaluated in the unit test:
#define RAPIDJSON_ASSERT(x) (!(x) ? throw AssertException(RAPIDJSON_STRINGIFY(x)) : (void)0u)
The existing checks triggered undefined behavior when the stack was empty (null pointer). This change avoid this:
* If `stackTop_` and `stackEnd_` are null, it results in a `ptrdiff_t` of `0`
* If `stackTop_` and `stackEnd_` are valid pointers, they produce a `ptrdiff_t` with the remaining size on the stack
