Add std::shared_ptr support

[Hippid]

Hi,
Thank you for this awesome project.
I chose your json library since I'm using a few classes that use std::shared_ptr and your library had some examples of how to use it.

Anyway I wanted to do something like this:
(see IModel.h below for implementation details)

JSONCONS_STRICT_MEMBER_TRAITS_DECL(std::shared_ptr<mynamespace::Model>, path, x, y, z)
JSONCONS_STRICT_MEMBER_TRAITS_DECL(std::shared_ptr<mynamespace::IModels>, Models)

Unfortunately this did not work and implementing it like the examples do would cause a bunch of repetitive code.

To solve this problem I made macro and was wondering if you could add it to the jsoncons project and examples.

#define JSONCONS_ADD_SHARED_PTR_MEMBER(ValueType, ...)  \
JSONCONS_STRICT_MEMBER_TRAITS_DECL(ValueType, __VA_ARGS__) \
namespace jsoncons { \
	template<class Json> \
	struct json_type_traits<Json, std::shared_ptr<ValueType>> { \
		static bool is(const Json& j, const ValueType& v) noexcept { \
			return j.is<ValueType>(); \
		} \
\
		static std::shared_ptr<ValueType> as(const Json& j) { \
			return std::make_shared<ValueType>(j.as<ValueType>()); \
		} \
\
		static Json to_json(const std::shared_ptr<ValueType>& ptr) { \
			if (ValueType* p = dynamic_cast<ValueType*>(ptr.get())) { \
				Json j(*p); \
				return j; \
			} else { \
				throw std::runtime_error("Not " + typeid(ValueType).name); \
			} \
		} \
	}; \
} \

Note: It internally uses the JSONCONS_STRICT_MEMBER_TRAITS_DECL macro and simply adds a bit of wrapper code to support the 'std::shared_ptr' method variant.
Therefore the 'normal' variant (that does not use std::shared_ptr) is also supported with this macro.
Since it uses the existing macro it works out of the box with features like std::vector.

Anyway the usage is now short and clean :)

JSONCONS_ADD_SHARED_PTR_MEMBER(mynamespace::IModel, path, x, y, z)
JSONCONS_ADD_SHARED_PTR_MEMBER(mynamespace::IModels, Models)

std::shared_ptr<IModels> jsonMethod(std::string inputJsonFile = "input.json) {
    std::ifstream is(inputJsonFile);
    json j = json::parse(is);
    return j.as<std::shared_ptr<IModels>>();
}

IModel.h

#include <vector>
#include <string>

namespace mynamespace {
	class IModel {
	public:
            inline IModel() {
                path = "";
                x = 0;
                y = 0;
                z = 0;
            };

            inline IModel(std::string _path, int _x, int _y, int _z) {
                path = _path;
                x = _x;
                y = _y;
                z = _z;
            };
        
            std::string path;
            int x;
            int y;
            int z;            
	};
	
	class IModels {	
	public:
            inline IModels() {
            };
            std::vector<std::shared_ptr<IModel>> Models;
    };
}

Regards,

Twan Springeling

[danielaparker]

Thank you for making this suggestion.

I would suggest separating the two macros , as they're orthogonal, and JSONCONS_ADD_SHARED_PTR_MEMBER can be used in conjunction with any of the _DECL variants. So let's start with:

#define JSONCONS_ADD_SHARED_PTR_MEMBER(ValueType, ...)  \
namespace jsoncons { \
    template<class Json> \
    struct json_type_traits<Json, std::shared_ptr<ValueType>> { \
        static bool is(const Json& j, const ValueType& v) noexcept { \
            return j.is<ValueType>(); \
        } \
\
        static std::shared_ptr<ValueType> as(const Json& j) { \
            return std::make_shared<ValueType>(j.as<ValueType>()); \
        } \
\
        static Json to_json(const std::shared_ptr<ValueType>& ptr) { \
            if (ptr.get() != nullptr) { \
                Json j(*ptr); \
                return j; \
            } \
            else { \
                return Json::null();  \
            } \
        } \
    }; \
} 

I've made one change from your code, since whatever is passed to

to_json(const std::shared_ptr<ValueType>& ptr) 

must have element type ValueType, the dynamic cast check is redundant. However, the stored pointer could be null, so that needs to be checked.

You can now declare

JSONCONS_STRICT_MEMBER_TRAITS_DECL(mynamespace::IModel, path, x, y, z)
JSONCONS_STRICT_MEMBER_TRAITS_DECL(mynamespace::IModels, Models)
JSONCONS_ADD_SHARED_PTR_MEMBER(mynamespace::IModel)
JSONCONS_ADD_SHARED_PTR_MEMBER(mynamespace::IModels)

and write (as before)

auto models = jsoncons::decode_json<std::shared_ptr<mynamespace::IModels>>(is);

or

json j = json::parse(is);
auto models = j.as<std::shared_ptr<mynamespace::IModels>>();

In the general case, though, this implementation of JSONCONS_ADD_SHARED_PTR_MEMBER isn't enough. In the general case, we can have e.g.

class Employee {};
class HourlyEmployee : public Employee{}; 
class CommissionedEmployee : public Employee{}; 

// Container of pointers to `HourlyEmployee` and `CommissionedEmployee` objects
std::vector<std::shared_ptr<Employee>> employees;

A general solution for JSONCONS_ADD_SHARED_PTR_MEMBER must generate a to_json that knows how to convert a std::shared_ptr<Employee> into a json value with the properties of either an HourlyEmployee or a CommissionedEmployee. And an as that knows how to convert a json value to the right specialization of Employee.

I had thought about this before, but wasn't able to come up with a satisfactory solution, so that's why that polymorphic example is half using _DECL macros and half custom code. But let me think about this again.

Best regards,
Daniel

[Hippid]

Hi Daniel,

I would suggest separating the two macros , as they're orthogonal, and JSONCONS_ADD_SHARED_PTR_MEMBER can be used in conjunction with any of the _DECL variants.

Yes, I fully agree.
I switched my code today from JSONCONS_ADD_SHARED_PTR_MEMBER with a separate JSONCONS_MEMBER_TRAITS_DECL macro (non strict version) and then came to the same conclusion.

---

I then switched JSONCONS_MEMBER_TRAITS_DECL to JSONCONS_GETTER_CTOR_TRAITS_DECL, since using a constructor would look better, but still have a small issue there.

JSONCONS_GETTER_CTOR_TRAITS_DECL actually works as a JSONCONS_STRICT_GETTER_CTOR_TRAITS_DECL macro and JSONCONS_STRICT_GETTER_CTOR_TRAITS_DECL does not exist.
Note: I expected that JSONCONS_GETTER_CTOR_TRAITS_DECL would not throw an exception when a key field was missing in the .json file. I expected it would work the same way as JSONCONS_MEMBER_TRAITS_DECL vs JSONCONS_STRICT_MEMBER_TRAITS_DECL is implemented, though this was not the case.

In the general case, though, this implementation of JSONCONS_ADD_SHARED_PTR_MEMBER isn't enough. In the general case, we can have e.g.

class Employee {};
class HourlyEmployee : public Employee{}; 
class CommissionedEmployee : public Employee{}; 

// Container of pointers to `HourlyEmployee` and `CommissionedEmployee` objects
std::vector<std::shared_ptr<Employee>> employees;

A general solution for JSONCONS_ADD_SHARED_PTR_MEMBER must generate a to_json that knows how to convert a std::shared_ptr<Employee> into a json value with the properties of either an HourlyEmployee or a CommissionedEmployee. And an as that knows how to convert a json value to the right specialization of Employee.

I had thought about this before, but wasn't able to come up with a satisfactory solution, so that's why that polymorphic example is half using _DECL macros and half custom code. But let me think about this again.

Best regards,
Daniel

I think the polymorphic the example is fine for now and would need a different issue since implementing that would be allot more work ;)

Anyway, from the top of my head you could do something like this:

Create a new macro that add the unique relations of the polymorphic structure before the _DECL macros are called. The _DECL macros can then generate the linking code when needed.

This way the generated methods of the inherited classes can internally call it's base class from/to json methods.

The macro would look something like this macroname( BaseType, InheritType, uniqueTypeField )

Example:

JSONCONS_LINK(ns:Employee, ns:HourlyEmployee, type)
JSONCONS_LINK(ns:Employee, ns:CommissionedEmployee, type)

JSONCONS_GETTER_CTOR_TRAITS_DECL(ns::Employee, firstName, lastName)

// Note: No firstname and lastname required, since they could be inherited from the base.
JSONCONS_GETTER_CTOR_TRAITS_DECL(ns::HourlyEmployee, wage, hours)
JSONCONS_GETTER_CTOR_TRAITS_DECL(ns::CommissionedEmployee, baseSalary, commission, sales)

Best regards,

Twan

[danielaparker]

I then switched JSONCONS_MEMBER_TRAITS_DECL to JSONCONS_GETTER_CTOR_TRAITS_DECL, > since using a constructor would look better, but still have a small issue there.

Note: I expected that JSONCONS_GETTER_CTOR_TRAITS_DECL would not throw an exception
when a key field was missing in the .json file. I expected it would work the same way as
JSONCONS_MEMBER_TRAITS_DECL vs JSONCONS_STRICT_MEMBER_TRAITS_DECL is
implemented, though this was not the case.

I don't think it could work exactly the same, as data members can be set in arbitrary order, while parameters to constructors must be passed in an assumed order.

Given e.g.

class A
{
public:
    A(int arg1, int arg2, int arg3);

   int arg1() const;
   int arg2() const;
   int arg3() const;
};

JSONCONS_GETTER_CTOR_TRAITS_DECL(A,arg1,arg2,arg3)

JSONCONS_GETTER_CTOR_TRAITS_DECL generates a call to A's constructor that looks something like

A(j["arg1"].as<int>(), j["arg2"].as<int>(),j["arg3"].as<int>()); 

and so will throw if any of "arg1", "arg2", or "arg3" are missing.

What we could do is if any of "arg1", "arg2", or "arg3" were missing, say if "arg2" was missing, A's constructor would be called with only arguments up to that point, i.e.

A(j["arg1"].as<int>());

which would compile if A's constructor supplied default values for arg2 and arg3. But then j["arg3"].as<int>() would end up unused, even if it existed.

Daniel

[danielaparker]

I've added a new convenience macro to master for generating json_type_traits for polymorphic types,

JSONCONS_POLYMORPHIC_TRAITS_DECL(base_class_name,derived_class_name0,derived_class_name1,...) 

For your example, usage is

JSONCONS_STRICT_MEMBER_TRAITS_DECL(mynamespace::IModel, path, x, y, z)
JSONCONS_STRICT_MEMBER_TRAITS_DECL(mynamespace::IModels, Models)
JSONCONS_POLYMORPHIC_TRAITS_DECL(mynamespace::IModel,mynamespace::IModel)
JSONCONS_POLYMORPHIC_TRAITS_DECL(mynamespace::IModels,mynamespace::IModels)

For the employee example, usage is

JSONCONS_GETTER_CTOR_TRAITS_DECL(ns::HourlyEmployee, firstName, lastName, wage, hours)
JSONCONS_GETTER_CTOR_TRAITS_DECL(ns::CommissionedEmployee, firstName, lastName, baseSalary, commission, sales)
JSONCONS_POLYMORPHIC_TRAITS_DECL(ns::Employee, ns::HourlyEmployee, ns::CommissionedEmployee)

In the implementation of json_type_traits<Json,std::shared_ptr<base_class_name>>, as(const Json& j) determines the derived class by calling j.is<derived_class_nameN>() for each derived class in sequence, and when is returns true, returns std::make_shared<derived_class_nameN>(j.as<derived_class_nameN>()). If none return true, as returns an empty std::shared_ptr<base_class_name>().

For this to work, there must be some difference in the derived class data members, in the Employee example, it is enough that HourlyEmployee has data members wage and hours, and CommissionedEmployee does not. In the case that derived classes cannot be distinguished by data members, users have the option of adding an artificial variable to their classes, e.g. bool hourly = true, or alternatively implementing custom json_type_traits specializations for derived classes, with custom implementations of is that go beyond what the macros can generate.

to_json(const std::shared_ptr<base_class_name>& ptr) attempts derived_class_name* p = dynamic_cast<derived_class_nameN*>(ptr) for each derived class in sequence, and when dynamic_cast returns non-null, returns Json(*p). If none return non-null, to_json returns Json::null().

Daniel

[danielaparker]

Support for polymorphic types is included in v0.138.0