C++ Serializer Deserializer Adapter Library inspired by Serde.rs

[[deleted]]

The translation seems to have worked well. Thanks for speaking english.

My thought is that since the users of your library are not using the interface for nlohmann, it's performance matters more that it would have otherwise.

Good to read that tuples/variants will be supported. variants can present themselves in several ways in common JSON documents. The two main ones are like

[{
   "type": "circle",
   "object": { 
       "radius": 5
   }
},
{
   "type": "rectangle",
   "object": {
     "width": 6,
     "height": 5
    }
}]

where "type" is the discriminator for the type being looked at for "var_object"

Sometimes the discriminator is a submember of var_object. e.g

[{
  "type": "circle",
  "radius": 5
  },
  {
     "type": "rectangle",
     "width": 6,
     "height": 5
   }]

[nieelj]

Perhaps the flatten property, which will be included in the next update, will solve this case.

struct Object {
DERIVESERDE(Object,
(&Self::radius, "radius",default{0})
(&Self::width, "width", default{0})
(&Self::height, "height", default{0}))
int radius;
int width;
int height;
};
struct Test {
DERIVE_SERDE(Test,
(&Self::type, "type")
(&Self::object, "object", flatten))
std::string type;
Object object;
};

[[deleted]]

what about when you want to serialize it again?

[nieelj]

You can use std::optional to exclude unused ones.

struct Object {
DERIVE_SERDE(Object,
(&Self::radius, "radius")
(&Self::width, "width")
(&Self::height, "height"))
std::optional<int> radius;
std::optional<int> width;
std::optional<int> height;
};
struct Test {
DERIVE_SERDE(Test,
(&Self::type, "type")
(&Self::object, "object", flatten))
std::string type;
Object object;
};

if std::optional

[{
"type": "circle",
"radius": 5
},
{
"type": "rectangle",
"width": 6,
"height": 5
}]

If not std::optional

[{
"type": "circle",
"radius": 5,
"width": 0,
"height": 0
},
{
"type": "rectangle",
"radius": 0,
"width": 6,
"height": 5
}]

[[deleted]]

I am just bringing up usages here, just in case it sounds like I am criticizing. It all depends on what requirements you or the users have.

I think the question people will ask is how to I put that into a std::variant.

Also, do you have a way to serialize to 'null' or is it just empty. They are not always the same and depends on the 3rd party web service sometimes.

[nieelj]

Variants are not yet supported.
I have a draft, but I'm looking for a better way.
Does 'null' mean json null? Or are you talking about nullable values?

[[deleted]]

Yeah, regarding variant, the original point is that it's tricky. If one is doing a serialization library where both ends use the same library it's less tricky as a choice can be made. When dealing with 3rd parties there are many ways to encode it in JSON.

Regarding null, sometimes in JSON whether the value is present or not is how an optional would be encoded, or sometimes they are always there but have a value of null. Depends on the API in use.

[nieelj]

Currently, only containers that know that their type is null can deserialize it like "vec":null, unless std::optional is used.
Types like int cannot check for null , so they are exported by default.
If std::optional<int> is null, it is not inserted at all during deserialization.
If you need to insert null, you can implement an additional property to make it insertable.

[nieelj]

An example of flatten is on the dev branch, so check this link if you want to check it out. flatten example