A change to the semantics of equality operator rewriting in C++20 (P2468R2: The Equality Operator You Are Looking For) means that operator== may not be rewritten with reversed operands if operator!= is also defined. Since operator!= can normally be synthesized from operator== regardless in this language standard, we can and should avoid defining those when the new language semantics are available.
This fixes the compilation of tests (and probably consuming code) in C++20 onwards for compilers that implement this new semantic, including recent nightly builds of clang-16.
Reference: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2468r2.html
Fixed DigitGen to use proper suffix for uint64_t numeric types. Change from U suffix to ULL suffix.
On SLED 11.0 compiler, code would not compile.
cd rapidjson-master
g++ -Wall -m32 -ggdb -Iinclude -O1 ./example/simpledom/simpledom.cpp -o simpledom 2>&1 | tee out.txt
Fixing compiler error on older compilers, such as SLED 11.0.
cd rapidjson-master
g++ -Wall -m32 -ggdb -Iinclude -O1 ./example/simpledom/simpledom.cpp -o simpledom 2>&1 | tee out.txt
Changed SIZE_MAX to std::numeric_limits<size_t>::max() in code to get rid of SIZE_MAX error.
These operators call themselves recursively if C++20 semantics are present in the compiler, regardless of standard library support for the operator; therefore the test should be on __cpp_impl_three_way_comparison, not __cpp_lib_[...].
This fixes the Value.EqualtoOperator test when the language standard is set to C++20 and the standard library does not yet define the library support macro.
operator[]() was recently changed to use the existing code in order to
correctly align the returned pointer; however this broke
-Wexit-time-destructors. Change to a method that is still correctly
aligned but does not generate a destructor.
operator[]() was recently changed to use the existing code in order to
correctly align the returned pointer; however this broke
-Wexit-time-destructors. Change to a method that is still correctly
aligned but does not generate a destructor.
Add the typedef declaration `StackAllocatorType` to the class template
`GenericDocument`. This allows the user to access the template parameter
`StackAllocator`.
When using operator[] on a GenericValue type clang-tidy complains,
appropriately, about the alignment of the buffer used for placement-new
of the "dummy" GenericValue.
When RAPIDJSON_USE_MEMBERSMAP is defined, an object Value will store
its members in an (re)allocated array of Members like before, but also
in an std::multimap<GenericValue::Data,SizeType> where the key and value
reference the corresponding Member by its Data and index in the array,
respectively, and in a relocatable manner.
The layout of the members map/array is now:
{multimap*}<>{capacity}<>{Member[capacity]}<>{multimap::iterator[capacity]}
where <> stands for the RAPIDJSON_ALIGN-ment of each part, if needed.
This layout needs to be reallocated when the current capacity is
exhausted, which requires to take care of the multimap and its iterators
explicitely. The multimap is allocated separately and only its pointer is
saved in this layout, so it can easily be restored in its new position.
As for the old/alive iterators, they must move to their new offset according
to the new capacity.
With this in place, it's immediate to get the multimap::iterator from a
MemberIterator and vice versa, thus the same complexity applies for the
operations with MemberIterator or MapIterator.
For FindMember() and RemoveMember(), the complexity drops from O(n) to
the multimap/rbtree's O(log n).
For EraseMember() it drops from O(n-m) to O((log n)-m), m representing
the move/copy of the trailing members.
For AddMember() though, the complexity grows from O(1) to O(log n) due to
the insertion in the multimap too.
Consequently parsing will be slower, up to ~20% measured in perftests on
my laptop (since it's mainly composed of insertions). But later work on
the Document (usually the goal of parsing...) will be much faster; the
new DocumentFind perftest included in this commit is 8 times faster with
RAPIDJSON_USE_MEMBERSMAP (still on my laptop). Overall the tests are 4%
slower (mainly composed of parsing), and notably 15% slower for schemas
parsing/validation (which supposedly comes from the larger JSON files
parsing, still). As a side note, when RAPIDJSON_USE_MEMBERSMAP is not
defined, this commit does nothing (same results for perftest with regard
to previous versions).
Finally, the multimap is allocated and constructed using StdAllocator,
so they will use the same Allocator than for any other Value allocation,
and thus will benefit from the same performance/safety/security/whatever
provided by the user given Allocator.
