In order to make the constructors more efficient, especially
in the context of C++11 move semantics, the (dynamic) allocations
in MemoryPoolAllocator and Stack should be performed lazily.
Move the allocations to the first use of the allocator in both
classes.
As mentioned in #181, some environments may require adaptations to
the internal calls to the global `new`/`delete` operators, like
adding explicit `NULL` checks to `delete.
This patch adds two new macros
* RAPIDJSON_NEW(x)
* RAPIDJSON_DELETE(x)
to allow user-defined expressions in these cases.
This fixes#181 in an alternative manner.
In the original disambiguation fix for `GenericValue::operator[]` (#170),
the documentation has been missing, which led to quite badly rendered
Doxygen pages.
During a cleanup, I've realized that a much simpler disambiguation is
possible:
````cpp
GenericValue& operator[](SizeType idx); // array
template <typename T>
GenericValue& operator[](T* name); // object
````
This approach works, as non-template functions are preferred over
template functions.
In order to improve the error messages, the pointer type is restricted
to `(const) Ch`.
Update `tutorial.md` to drop the ambiguity warning.
MemoryStream::Peek() did not return '\0' if src_ == end_, but Peek() == '\0' is
used in parsing in the GenericReader. Without this change, parsing with
MemoryStream as the InputStream could result in a segmentation fault.
Some compilers do not export the standard C library functions
to the global namespace, in case the C++ header variants are
included (<cstdlib>, <cstring>).
RapidJSON currently uses:
* malloc, realloc, free
* memcpy, memmove, memset, memcpy
Add an explicit namespace qualification to avoid lookup problems.
For more details see: https://github.com/miloyip/rapidjson/issues/132
This commit tries to minimize the required code changes and forwards the `Handler::Key()` calls to `Handler::String()` wherever possible in order to not break existing code; or at least not code deriving from `BaseReaderHandler` when implementing a custom `Handler`.
The `ShortString` can represent zero-terminated strings up to `MaxSize` chars (excluding the terminating zero) and store a value to determine the length of the contained string in the last character `str[LenPos]` by storing `MaxSize - length` there. If the string to store has the maximal length of `MaxSize` (excluding the terminating zero) then `str[LenPos]` will store `0` and therefore act as the string terminator as well. For getting the string length back from that value just use `MaxSize - str[LenPos]`.
This allows to store `11`-chars strings in 32-bit mode and `15`-chars strings in 64-bit mode inline (for `UTF8`-encoded strings).
Since the payload (the `Data` union) of the current implementation of `GenericValue` is `12 bytes` (32 bit) or `16 bytes` (64 bit) it could store `UTF8`-encoded strings up to `10` or `14` chars plus the `terminating zero` character plus the string length:
``` C++
struct ShortString {
enum { MaxSize = sizeof(GenericValue::String) / sizeof(Ch) - sizeof(unsigned char) };
Ch str[MaxSize];
unsigned char length;
}; // at most as many bytes as "String" above => 12 bytes in 32-bit mode, 16 bytes in 64-bit mode
```
This is achieved by introducing additional `kInlineStrFlag` and `kShortStringFlag` flags. When setting a new string value in `SetStringRaw(s, alloc)` it is first checked if the string is short enough to fit into the `inline string buffer` and if so the given source string will be copied into the new `ShortString` target instead of allocating additional memory for it.
As mentioned by @kosta-github in http://git.io/0gkYSg, the currently
used growth factor of 2 is suboptimal for memory performance. An
extensive discussion can be found at [1].
This patch reduces the array/object capacity growth factor to 1.5, as
many C++ implementations have chosen to use. In order to avoid
floating-point arithmetics for computing the new capacity, I did not
add any customization parameter for the factor and used a shift+add
instead.
[1] https://github.com/facebook/folly/blob/master/folly/docs/FBVector.md
Some 64-bit integers cannot be represented losslessly as a double.
Due to a typo in the operator==, the comparison has been performed
after a double conversion in too many cases.
Added basic detection of `noexcept` support for some compilers, added
corresponding RAPIDJSON_NOEXCEPT annotations to
* non-allocating constructors
* (move) assignment
* Swap
