Re: [boost] Interest in serialization library

Subject: Re: [boost] Interest in serialization library
From: iwg molw5 (iwg.molw5_at_[hidden])
Date: 2012-12-28 00:39:54

As requested, this post summarizes the major differences between
Boost.Serialization and the "serializable" library.  To begin, I will
examine the two libraries in the context of this library's motivating
use-case - protocol specification.  It is not uncommon for an application
to require full control over how it's data is laid out on the wire,
common examples here include network protocols and proprietary archive
formats.  Native C++ implementations generally follow the following
pattern:

  struct Object
  {
      uint32_t x;
      uint32_t y;
  };

  void read (Stream& in, Object& out)
  {
      out >> out.x >> out.y;
      ntohl(out.x);
      ntohl(out.y);
  }

  void write (Object const& in, Stream& out)
  {
      out << htonl(in.x) << htonl(in.y);
  }

The primary advantage of this library over an implementation similar to
the above is zero duplication of intent.  A reformulation of the above
follows:

  struct Object : serializable <Object,
      value <NAME("x"), big_endian <uint32_t>>,
      value <NAME("y"), big_endian <uint32_t>>>
  {
  };

Boost.Serialization is difficult to compare here - it is not really
intended for this sort of application.  A naive implementation using a
binary archive, or similar, would likely result in code very similar to
the basic read/write pattern given above, especially if the byte ordering
is inconsistent across the message.  On the other hand it is not at all
clear to me that a superficial extension of Boost.Serialization could not
be used here to simplify this task dramatically - comments are welcome.

With the above in mind, the serializable library can accommodate other
use-cases.  For example, Boost.Serialization excels at applications
(with some caveats of course) where the layout of data may be uniformly
defined across the archive.  Here the two are much easier to  compare -
specifically, this library allows for:

  1. Zero duplication of intent
  2. Little or no overhead over a native C implementation
  3. Generic access to the container

Point 3 above is worth expanding on - as an object's specification is
contained within it's type information generic methods may be written
that interact with the object's fields, not unlike Boost.Fusion.  In
particular, the exposed field names are used to implement a set of
generic member-wise comparison methods between a pair of arbitrary
serializable objects:

  inline_object <value <NAME("x"), int>> o1 {0};
  inline_object <value <NAME("y"), float>> o2 {1};
  assert(less_than(o1 < o2));

On the other hand, Boost.Serialization retains some serious advantages
here, such as:

  1. Feature rich (native versioning/pointer/... support)
  2. Portability (serializable requires C++11)
  3. No member-access syntax overhead

Again the third point above is worth expanding on - this  library
identifies variables by typename.  Specifically, the NAME macro  maps a
string literal to a unique identifier used to access the  associated
variable.  As a result, there is a syntax overhead over a raw C
structure.  Some examples:

  struct Object : serializable <Object,
  value <NAME("x"), int>>
  {
      ...

      int foo ()
      {
          return base <NAME("x")>::get() + 1;
      }
  };

  int foo (Object& t)
  {
      return get <NAME("x")> (t) + 1;
  }

To summarize then - the performance of the two libraries varies
dramatically depending on the use-case in question.  I hope the above
sufficiently illustrated the major differences between the two - if not,
comments are welcome.

On Thu, Dec 27, 2012 at 8:42 PM, Andrey Semashev
<andrey.semashev_at_[hidden]>wrote:

> Does your library support non-intrusive approach of adding serialization
> support to user's classes? How does it compare to Boost.Serialization in
> terms of features and performance?
>
>
>
>
> ______________________________**_________________
> Unsubscribe & other changes: http://lists.boost.org/**
> mailman/listinfo.cgi/boost<http://lists.boost.org/mailman/listinfo.cgi/boost>
>

Non-intrusive serialization is supported in a manner similar to that used
by Boost.Serialization.

The feature set provided by the library is fairly limited compared to
Boost.Serialization, particularly in areas where Boost.Serialization
excels - see above.

The performance of the library is difficult to comment on.  The
serializable library does not introduce any intrinsic overhead over an
equivalent set of operations performed on a raw C structure - does that
answer your question?