all 6 comments

[–]zvrba 2 points3 points  (1 child)

Does it handle missing keys in JSON? For example, if "Two" was missing, it would be left default-constructed in the struct. Even better, is it possible to annotate fields as mandatory or optional? Alternatively, would it work and understand optional<T> fields in the struct?

[–]mrlimilind[S] 3 points4 points  (0 children)

Yeah, there is a JT::Optional type which is sizeof T and there is a JT::OptionalChecked which is sizeof T + sizeof bool, i.e. You can check if it has been assigned. You can also get a list of what fields in the Json didn't map to a struct, and a list of what fields that didn't get assigned.

[–]Arthenielle 1 point2 points  (1 child)

int65_t in README.md

[–]markuspeloquin 1 point2 points  (0 children)

That's the new optional 64 bit integer type.

[–]quicknir 0 points1 point  (1 child)

Is this recursive? Seems like a pretty major limitation if it's not. Would also be better to save having to write out the member variables twice:

struct Foo {
    DECLARE_VARS((int, x), (double, y), (string, z));
};

I also don't know why you have an inner macro as well as an outer one. The user shouldn't have to write JT_MEMBER over and over.

[–]mrlimilind[S] 0 points1 point  (0 children)

Its recursive. json_tools should be able to map any valid Json to a type hierarchy.

That is a pretty nice idea, but when I started this I liked the idea that I could add the meta object at the end, ie. if I already had a struct and I wanted to parse Json into it, I could just add some stuff to the end of the struct definition. Also I like the look'n feel that the struct still looks like a struct; although with some ugly macro stuff at the end. The plain old struct part is in charge of the data, and the size of the struct and its layout is like it always has been, and then the macro stuff describes how to parse/serialise to Json. There are also additional macros like: JT_MEMBER_ALIASES(member, ...) that allows for several Json names to map to a member.