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@gmail.com>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?