In case of a user-defined RAPIDJSON_PARSE_ERROR_NORETURN that throws
an exception instead of using the Rapidjson ParseError API, the early
return paths performing the stack unwinding manually can be omitted as
well.
This patch provides a customizable RAPIDJSON_PARSE_ERROR_EARLY_RETURN
macro to remove these (then unneeded) control paths from the parsing
implementation (with and without a return value).
Secondly, clearing the parse stack is moved to a small helper struct
that calls stack_.Clear() from its destructor. This avoids the need
for the 'goto' in the ParseStream function and ensures proper cleanup
even if e.g. a user-defined Allocator throws an exception.
In order to enable the customization of the error macros
- RAPIDJSON_PARSE_ERROR_NORETURN
- RAPIDJSON_PARSE_ERROR_EARLY_RETURN
the user may need to have access to the ParseErrorCode enum
already. This requires a separate header location than the
GenericReader.
While MSVC doesn't like the explicit `.template operator=<...>` syntax
(see 4f40ed6), Clang 3.5 complains about the absence of it:
In file included from ../../test/perftest/rapidjsontest.cpp:6:
../../include/rapidjson/document.h:504:18: error: use 'template' keyword to treat 'operator =' as a dependent template name
return (*this).operator=<StringRefType>(str);
^
template
Delegate both operator=(StringRefType) and operator=(T) to operator(GenericValue&).
There are two copies of `StrLen` in the RapidJSON code base
* strfunc.h: rapidjson::internal::StrLen<Ch>
* unittest.h: Strlen<Ch>
To hide a warning on MSVC, align both implementations to use
'unsigned/SizeType' as return type and add an explicit cast.
The `StringRefType` assignment operator overload
leads to a compiler error on MSVC 2005 and later:
..\..\include\rapidjson/document.h(504) : error C2951: template declarations are only permitted at global, namespace, or class scope
Drop the unneeded 'template' keyword here.
MSVC with enabled RAPIDJSON_SSE2/RAPIDJSON_SSE42 requires the explicit
definition of the `_BitScanForward` intrinsic. This can be reliably
ensured by including "intrin.h" and properly marking '_BitScanForward'
as intrinsic.
Confirmed on MSVC 2005, 2008.
Should fix https://code.google.com/p/rapidjson/issues/detail?id=96
With the new string handling API, the constructor taking a `bool`
parameter matches in some unwanted cases, as pointers can be casted
to `bool` implicitly.
Add a SFINAE helper to this constructor to avoid matching arbitrary
pointers. To avoid confusion for the user, this mechanism is hidden
from the Doxygen documentation.
