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.
Warning push/pop support has been added to GCC in version 4.6.0,
and pragmas to ignore certain warnings are present since 4.2.0.
This patch hides the compiler-specific warning push/pop/disable
pragmas behind a macro-based implementation (currently for MSVC and
clang /GCC.
This avoids warnings, as seen e.g. on GCC 4.4:
../../include/rapidjson/document.h:14: error: expected [error|warning|ignored] after ‘#pragma GCC diagnostic’
and earlier versions complaining about unknown pragmas being ignored.
Note: unittest.h and perftest.h need to check for compilers
explicitly, as rapidjson.h is not included there.
Although not yet complete, the rapidjson.h header contains most of
the customisation macro definitions. These should be documented via
Doxygen as well. This requires adding file-level documentation.
Some parts are excluded via `@cond` to avoid cluttering the documentation
with internals too much.
Secondly, a brief description is added to the 'rapidjson' namespace to
include the namespace-level elements (enums, typedefs, functions) to
the generated documentation.
The error messages in ParseNumber used `is.Tell` to report the
position of the number parsing error. Depending on the copy
optimization of the current stream, this can lead to different
behaviour (beginning of number vs. position of error).
* Delegate constant string construction to SetStringRaw
* Delegate "const Ch*" overloads to GenericValue variants
of operator[], FindMember and RemoveMember
* Remove repeated template arguments in nested struct Array
(cherry-picked from ca9b0332d)
Instead of hard-coding the value 0 for the parseFlags in the
various parsing overloads, explicitly use kParseDefaultFlags
to provide more self-documenting code.
