Templated accessors and range-based for

[miloyip]

Fix #316, #162, #212

Request for code review

[pah]

Typo here: ArratType?

[pah]

👍 LGTM, thanks!

I haven't seen a conversion from Generic(Array|Object) back to GenericValue. Wouldn't this conversion be helpful to move the contents of an Array/Object back into another Value? The only challenge would be to restore the kArrayType|kObjectType invariant after moving from the nested Value. What do you think? Maybe, it's better to add additional (but here non-explicit) constructors to GenericValue?

[miloyip]

There are GenericValue::SetArray|Object(Array|Object&) already.
I do not understand

The only challenge would be to restore the kArrayType|kObjectType invariant after moving from the nested Value.

Maybe a (move) constructor and assignment will be more complete.
How about other similar operations such as PushBack(Object|Array), AddMember(...), etc?

[pah]

There are GenericValue::SetArray|Object(Array|Object&) already.

Yes, but no GenericValue(Object/Array) constructors, allowing to directly move an array/object to another value. With such (implicit) constructors (and assignments), wouldn't it be sufficient for all other uses? Adding another bunch of overloads to all value-accepting functions sounds like a lot of boiler-plate to me.

  GenericValue(Object o) : RAPIDJSON_NOEXCEPT : data_(), flags_(kNullFlag) {
    RAPIDJSON_ASSERT(o.ptr_);
    RawAssign(*o.ptr_);
    o.ptr_->SetObject(); // maintain invariant
  }

[pah]

After this call, a.ptr_ is null, not an (empty) array. We should add an a.ptr_->SetArray(); here (set for SetObject(Object);` to avoid breaking the invariant.

Secondly, we should check for a.ptr_ not being NULL in an assert, which could happen due to a default constructed Array|Object instance.

[miloyip]

Thank you @pah