Hi Sohail,
Also, in some cases I had goals that were simply not included in Boost implementations. Boost.Serialization does not have runtime encoding selection.
The polymorphic archives do allow this.
They assist you towards that goal. But considering the two libraries somehow equivalent in this area would be misleading. In the docs it describes the motivation/solution according to polymorphic archives. It describes the construction of sets of archive implementations, e.g. you can build an application with text and wide text or text and binary, etc. It also shows the selection of a specific archive (e.g. text); boost::archive::polymorphic_text_oarchive oa(ss); boost::archive::polymorphic_oarchive & oa_interface = oa; How does the user of the application or even the developer select a different encoding? Given the example it would take a recompilation. The Pact library selection is innately runtime strings; load( object, "file", "Neat Bytes" ); While changing the line above would also require a recompilation there is an obvious potential to pass strings into an application from command line arguments, environment variables or configuration data. The Pact library implements a "codec_factory" that takes care of all of that. This might seem trivial but there are pitfalls and some further issues. It's not enough to say that Boost.Serialization has the potential to do something similar (which is still unclear). Until it is a part of Boost.Serialization you cannot rely on any /standard/ collection of encodings and /standard/ naming of encodings. It would be interesting to get a survey of all uses of boost::archive::polymorphic. I'm sure there will be a variety of deployments - different sets of archives, different runtime selector types (enums, strings) and different values for those types. Now imagine trying to get these deployments to agree to a Boost /standard/ and you might see what I am trying to explain. Any software component developed in Pact can use any encoding available at any site. All the I/O primitives have the necessary selection parameters, the parameter type is fixed and the basic set of encodings available are standard. Using Boost you would have to ship a DLL with your components. And the user of your component may have to accept this arrangement for multiple components. The last point is how Boost.Serialization handles UDTs/ADTs. My understanding of this area is sketchy - it appears to rely on pointers to methods for archiving of such objects. The polymorphic interface passes a bald object through to the archive implementation and I'm guessing, onto a registered method pointer. The Pact library converts all objects including UDTs into a generic form before they enter the encoding machinery and there are no registered per-type method pointers. Once an object enters the "Pact world" it is type-less.Objects can travel between threads and across networks. As they pass between processes they can be serialized and de-serialized multiple times and in several different formats (i.e. archives/encodings). Achieving the same mobility with Boost.Serialization is at the very least difficult. Thanks for highlighting the issue, Scott