- 06 Dec, 2018 4 commits
-
-
Milo Yip authored
Fix off by one in FileReadStream::Peek4()
-
Milo Yip authored
Optimize FileReadStream and BasicIStreamWrapper.
-
Milo Yip authored
GenericRegex: don't throw/abort on syntax error (unclosed parenthesis).
-
ylavic authored
Until Read() reaches EOF, Peek4() must not take off by one in bufferLast_ into account; otherwise a buffer of size exactly 4 always returns NULL.
-
- 05 Dec, 2018 3 commits
-
-
ylavic authored
-
ylavic authored
-
ylavic authored
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.
-
- 03 Dec, 2018 4 commits
- 01 Dec, 2018 2 commits
- 22 Nov, 2018 2 commits
- 21 Nov, 2018 1 commit
-
-
Jean-Claude Monnin authored
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)
-
- 01 Nov, 2018 1 commit
-
-
Philipp A. Hartmann authored
Co-Authored-By: yhager <yhager@users.noreply.github.com>
-
- 26 Oct, 2018 1 commit
-
-
Yuval Hager authored
-
- 08 Oct, 2018 2 commits
-
-
Milo Yip authored
Add test case on kParseNumbersAsStringsFlag being able to load big ints
-
Lele Gaifax authored
See issue #1368.
-
- 19 Sep, 2018 2 commits
- 18 Sep, 2018 2 commits
-
-
Julien Courtat authored
GenericDocument contructor requires a pointer to an Allocator, but GetAllocator() only returns a reference. Signed-off-by: Julien Courtat <julien.courtat@aqsacom.com>
-
jiapeng.wen authored
-
- 11 Sep, 2018 1 commit
-
-
Milo Yip authored
Add RAPIDJSON_NOEXCEPT_ASSERT
-
- 10 Sep, 2018 7 commits
-
-
Milo Yip authored
Update appveyor rule to support VS2017.
-
Milo Yip authored
-
Minmin Gong authored
-
Milo Yip authored
-
Milo Yip authored
Fix the compiling problems in VS
-
Milo Yip authored
Guard against min/max being macros in reader.h
-
Milo Yip authored
Handle non-throwing exception specifications that can still throw #1280
-
- 05 Aug, 2018 2 commits
-
-
Milo Yip authored
Wrap all WriteXxx() calls within EndValue()
-
Lele Gaifax authored
-
- 03 Aug, 2018 2 commits
-
-
Lele Gaifax authored
-
Lele Gaifax authored
This attempts to fix issue #1336.
-
- 01 Aug, 2018 2 commits
- 31 Jul, 2018 2 commits
-
-
IceTrailer authored
-
Veselin Georgiev authored
Update RAPIDJSON_ALIGN() to always align on an 8-byte boundary unless otherwise overridden. On some platforms (such as ARM), 64-bit items (such as doubles and 64-bit integers) must be aligned to an 8 byte address, even though the architecture is only 32-bits. On these platforms, MemoryPoolAllocator must match the malloc() behavior and return a 8 byte aligned allocation. This eliminates any alignment issues that may occur at the expense of additional memory overhead. Failure to do so caused a SIGBUS signal when calling GenericValue::SetNull(). The size of the data_ member of the GenericValue class is 16 bytes in 32-bit mode and its constructor requires an 8-byte aligned access. While parsing a JSON formatted string using Document::ParseStream(), a stack object containing GenericValue items was constructed. Since the stack was 8-byte aligned, the constructor calls would succeed. When the lifetime of the object ends, SetObjectRaw() is invoked. This triggered an allocation with 4-byte alignment to which the previously 8-byte aligned GenericValue array was copied. After this, any call to a GenericValue API that triggered the constructor and thus the placement new operation on the Data type member would trigger a SIGBUS. Signed-off-by: Veselin Georgiev <veselin.georgiev@garmin.com> Signed-off-by: Joshua Watt <Joshua.Watt@garmin.com>
-