"Gennadiy Rozental" <gennadiy.rozental@thomson.com> wrote in message news:e2c2s5$l3n$1@sea.gmane.org... : > In case of tracking-ids I just wanted them out, because I do not have : > duplicate objects in human-created files. On the other hand, I couldn't : > disable tracking per-class, because I still wanted other archives to do : > tracking on these objects. A couple of days ago I even posted a question : > for Robert, and he says that I would need to create my own version of : > tracking.hpp. : > : > So as you can see it is not all roses with serialization library and human : > readable files. : : Well you need to bring it all to the Robert attention. Boost serialization : should support wide variety of archives, including simple xml. But can it? Can boost::serialization support an archive format that: - is easily human-readable, human-editable, and human-*writable* (which IMO excludes having "class ID" fields and such) - provides straightforward support for default values and optional fields, which is important for backwards compatiblity with older archives - will not bark at additional/not-understood fields that are present in the file (important for forward-compatibility) - provides support for archives that are read/written by other programming languages (as JSON does). By the current support for XML provided by boost::s11n, I doubt that these features can be easily provided. But I'd love to be proven wrong. Can you help us see the light ? I find you are being quite vocal against a library which obviously does not address a need that you have. But as Bjarne himself likes to admit, no one knows what most C++ programmers do. When I define a configuration or data file, I like to design it around what end-users will think is logical, not around the (current and possibly changing) representation of the data within my C++ program. Boost::s11n as it is today does not seem to support this approach. ptree does much better. And others have other reasons to like ptree. The fact that, for your needs, ptree doesn't allow anything that s11n doesn't already do, should NOT be a reason to reject the library. As I wrote elsewhere, regex and spirit are just as overlapping as ptree and s11n. Yet many needs are only served well by one of the two twin libraries. Regards, Ivan -- http://ivan.vecerina.com/contact/?subject=NG_POST <- email contact form