The C++ standard does not include the C99 macros used to set the (U)INT64
constants in document.h and reader.h (see adf66292 and ce1fece2).
Many implementations include their definition when the
__STDC_CONSTANT_MACROS preprocessor symbol is defined.
See e.g. http://www.cprogramdevelop.com/5272623/,
needed to successfully build in travis-ci.org's environment.
Travis CI is a free hosted continuous integration platform for
open-source projects. It allows automated testing for GitHub-hosted
projects.
This commit adds a corresponding `.travis.yml` configuration file.
This commit adds some simple tests for the deep-copying
of values, either based on the explicit constructor, or
the CopyFrom function.
It uses the CrtAllocator to test for possible double-free
errors due to insufficient copying.
To allow deep copying from an existing GenericValue, an
explicit "copy constructor" (with required Allocator param)
and an "CopyFrom" assignment function are added.
Document d; Document::AllocatorType& a = d.GetAllocator();
Value v1("foo");
// Value v2(v1); // not allowed
Value v2(v1,a); // make a copy
RAPIDJSON_ASSERT(v1.IsString()); // v1 untouched
d.SetArray().PushBack(v1,a).PushBack(v2,a);
RAPIDJSON_ASSERT(v1.Empty() && v2.Empty());
v2.CopyFrom(d,a); // copy whole document
RAPIDJSON_ASSERT(d.IsArray() && d.Size()); // d untouched
v1.SetObject().AddMember( "array", v2, a );
d.PushBack(v1,a);
Additionally, the Handler implementation in GenericDocument is made
private again, restricting access to GenericReader and GenericValue.
Instead of always just shallowly referencing the potentially allocated
strings when calling the Handler::String function, request a copy in
case the string has been allocated from an Allocator before.
This is necessary to avoid double free()s of the string memory,
especially when using the Handler to create a deep copy of a Value.
The explicit comparison against '0' is done to suppress the warning
C4800 on MSVC, see pah/rapidjson#5.
As proposed in other patches, it is convenient to pass a user-defined
precision for the (programmatic) output of a single double value
to an OutputStream.
This patch adds an additional overload with an explicit precision
argument to the (Pretty)Writer class templates.
Writing a double to an OutputStream current prints at most 6 significant
digits (according to the C standard).
The function SetDoublePrecision(), added to the Writer classes
can be used to fluently set the precision, i.e. the number of
significant digits to use for writing the double:
Writer<...> writer(...);
d.Accept(writer.SetDoublePrecision(12));
The MemoryPoolAllocator implementation cannot and should not be
copied (Rule of Three). Declare copy constructor and copy-assignment
operator as private.
The ParseStream() function current requires explicitly passing
the SourceEncoding parameter as explicit template argument
while the other Parse*() functions provide overloads to omit
this parameter and use the document's own encoding by default.
This patch adds the corresponding overload for ParseStream(),
enabling the simple usage again:
rapidjson::FileStream is(fp);
rapidjson::Document d;
d.ParseStream<0>(is);
In case of overloaded functions taking either a GenericValue or another
class that can also be constructed from the same primitive types
(e.g. std::string, which can be constructed from const char*), the
overloading becomes ambiguous:
void foo( const std::string& );
void foo( const rapidjson::Value & );
Declaring the GenericValue constructors taking primitive types as
'explicit' avoids this problem. This should not have any negative
side-effects, since a GenericValue can't be copied or implicitly
converted to other types.
Fixes http://code.google.com/p/rapidjson/issues/detail?id=70.
Constructing an empty GenericValue with a specific Type has failed
for any kNumberType (Int, Int64, Double...) due to incomplete definition
of the corresponding default flag value.
This patch adds a new constant kNumberAnyFlag to the flags enumeration
in GenericValue to cover this case.
This fixes http://code.google.com/p/rapidjson/issues/detail?id=57
In C++'98/03, trailing commas in enumerations are not allowed, but have
been introduced in C++11. This patch drops the trailing commas in order
to avoid compiler warnings (e.g. GCC with -pedantic).
Fixes http://code.google.com/p/rapidjson/issues/detail?id=49.