Igniters,
After some meditation on the matter I came to the following rough design.
We define 2 serialization modes - intrusive and non-intrusive.
1) Intrusive
Require user to define 3 static methods in his class:
static int TypeId(); // Type ID is used to distinguish different types.
static Write(IgniteWriter& writer, T* obj);
static T* Read(IgniteReader& reader);
Alternatively Write/Read methods can be moved to custom serializer and
registered in Ignite configuration. This allows for non-static reads/writes.
Pros: easy to use; fits well to new development; serialization logic is
bound to Ignite instance.
Cons: not available for types which cannot be changed; works only with raw
pointers;
2) Non-intrusive
User should define Read/Write functions for particular type and register
them with our macro as follows:
IGNITE_SERIALIZATION_REGISTER_TYPE(
Person, // Type to register.
my_proj::TypeIdPersion , // Type ID function.
my_proj::WritePerson, // Write function.
my_proj::ReadPerson // Read function.
)
This macro will expand into several overrides of well-known functions, thus
generating necessary serialization code in compile time.
Pros: no changes to existing code-base; can work with anything - values,
raw pointers, smart potiners, etc..
Cons: more actions from user are required, expanded functions have global
visibility.
We will use this approach internally to serialize primitive types,
collections, smart pointers, etc. E.g. once user registered his type T, he
will automatically be able to serialize std::vector<T>, std:;shared_ptr<T>,
etc..
Any thoughts?
Vladimir.
On Wed, May 27, 2015 at 11:57 AM, Branko Čibej <br...@apache.org> wrote:
> On 27.05.2015 09:06, Vladimir Ozerov wrote:
> > Code generation in any from (either compiile-time or runtime) is nice
> idea
> > and we certainly should pay attention to it. But it appears to be too
> > complicated for initial release.
> > I would stick to explicit "serializers" for now.
>
> Sure; I'm taking the long view here.
>
> -- Brane
>
> > On Wed, May 27, 2015 at 9:28 AM, Denis Magda <dma...@gridgain.com>
> wrote:
> >
> >> On 5/27/2015 12:14 AM, Branko Čibej wrote:
> >>
> >>> 2. Use a C++ parser (e.g., from LLVM) to generate a machine-readable
> >>> structure description, and generate the marshalling code from
> that.
> >>>
> >>> Option 2 is by far the most user-friendly, because users could just
> >>> point the generator to their existing class definitions. But it's
> >>> probably a huge amount of work.
> >>>
> >> Branko,
> >>
> >> This is really an awesome solution if we want to perform marshalling
> >> automatically.
> >>
> >> Apple extensively uses libclang for code analysis and generation in its
> >> Objective-C runtime.
> >> We can go the same way. Here is a good introductory article on clang:
> >> http://szelei.me/code-generator/
> >>
> >> --
> >> Denis
> >>
> >>
>
>
