A better C + + serialization/deserialization library Kapok

Kapok FAQ
Features of 1.Kapok
Simple, easy to use, header-only, only need to quote kapok.hpp, efficient, preliminary testing and messagepack equivalent.
It is a pure c++11 implementation and therefore requires a compiler that supports c++11.

2. Main functions
Automating the serialization and deserialization of objects is very simple, so let's take a look at the example of serializing/deserializing a tuple.

//Serialization ofSerializer Sr;auto TP= Std::make_tuple (Ten, A,string("Test") ); Sr. Serialize (TP,"tuple");//deserializationDeserializer dr;std::tuple<int,int,string>P;dr. Parse (Sr. GetString ());d R. Deserialize (p,"tuple");

It seems to be not very simple!

Let's look at an example of serializing a custom object.

structperson{intAge ; stringname; stringCity ; META (age, Name, city)}; Person P= { -,"BB","AA" };//Serialization ofSerializer SR;SR. Serialize (P," Person"); //deserializationDeserializer Dr; Person PERSON;DR. Parse (Sr. GetString ());d R. Deserialize (person," Person");

The same is simple, the structure needs a macro definition meta, the role of this meta is to obtain the object's meta-information, with this meta-information we can easily implement serialization and deserialization.

3. Application Scenarios
Kapok supports infinite nesting of structs (nested structs must also define meta macros) in addition to all objects that do not support pointers. Here's why pointers are not supported, because there are two problems with pointers in objects: 1. If this pointer is a dynamic array, the length of this array cannot be obtained in C + +, and 2. Pointers also involve memory management, and I want Kapok to focus on serialization and/or deserialization, without considering memory management for the time being.

4. Does the struct have to have a macro definition that is intrusive?
It seems that every serialized/deserialized object with a macro definition appears to be intrusive, but this intrusion is completely harmless, because it simply defines an extra function that will only be used when serializing/deserializing, not having any effect on the current object, and one thing because C + + is No reflection, there must be some way to get the object's meta-information, throughout the current serialization scheme, only this way is the most concise, the user to do the least thing, this is the reason I choose this way.

How 5.Kapok is implemented for serialization/deserialization
The bottom of the Kapok is the use of Rapidjson, using it to achieve the basic type of serialization, it made a simple package for the upper layer to use, the above is the serialization \ Deserialization implementation layer, mainly to achieve the object meta-information analysis and automated packaging and unpacking. Here is one of the Kapok serialization:

What is the performance of 6.Kapok
The initial test serializes/deserializes a tuple 10,000 times, discovering that Kapok is time-consuming and messagepack equivalent.

7.Kapok Support for multiple languages
Temporarily do not support, first of all the C + + version to do, if you want to support multiple languages, need to rewrite in other languages, more trouble, so temporarily do not consider supporting multiple languages.

By the way to publicize my organization's technical salon, welcome friends who love C + + registration, registration address point here.

A better C + + serialization/deserialization library Kapok