Re: [Boost-users] XML Serialization Traits Question

Robert,
I forced a crude solution by defining a custom XML output
archive and defining My_Archive::save_override(const nvp<T>&, int) as
below. This would double the class information in some objects, so I
also set the BOOST_CLASS_IMPLEMENTATION to object_serializable for my
serialized classes. It is crude, but seems to give me the results I
need.
class My_Archive : public
boost::archive::xml_oarchive_impl
Robert,
Thanks for the example; it helped clear up some uncertainty about the template arguments in the derived class.
Regarding save_override, I see where specialized versions for the different trait types are defined in basic_xml_oarchive.ipp. I also see that save_override is called from the operator<< redefinition in interface_oarchive.hpp. What I'm missing is the link between serializing a user-defined class object and the traits of that object.
template<class Archive> BOOST_ARCHIVE_OR_WARCHIVE_DECL(void) basic_xml_oarchive<Archive>::save_override(const version_type & t, int) { int i = t.t; // extra .t is for borland write_attribute(VERSION(), i); }
This function already displays a version attribute in the XML. How do
I make sure this is called for every element? I'm sorry, but I can't figure out how to modify chain of control to force output of class traits.
Starting in oserializer.hpp, boost::archive::save
calls static save_non_pointer_type ::invoke calls serialize_adl calls boost::serialization::serialize calls access::serialize calls myClass::serialize<Archive> (Archive& ar, unsigned int version) There is also a function oserializer
::save_object_data that
calls serialize_adl, but I can't find anything that calls it.
The struct save_non_pointer_type
in oserializer.hpp may be
the key, but I'm not sure how it works.
In oserializer.hpp, struct save_non_pointer_type
::save_standard::invoke calls Archive::save_object, but I do not see an implementation of the function anywhere: $ find /usr/include/boost -type f -exec grep -H save_object {} \;| grep -v save_object_ | more /usr/include/boost/archive/polymorphic_oarchive.hpp: virtual void save_object( /usr/include/boost/archive/detail/oserializer.hpp: ar.save_object(& t, oserializer
::instantiate()); /usr/include/boost/archive/detail/basic_oarchive.hpp: void save_object( /usr/include/boost/archive/detail/polymorphic_oarchive_impl.hpp: virtual void save_object( /usr/include/boost/archive/detail/polymorphic_oarchive_impl.hpp: ArchiveImplementation::save_object(x, bos); I'd appreciate any suggestions. Am I even looking in the right place?
Thanks in advance, Bill
-----Original Message----- From: boost-users-bounces@lists.boost.org [mailto:boost-users-bounces@lists.boost.org] On Behalf Of Robert Ramey Sent: Wednesday, July 26, 2006 12:14 PM To: boost-users@lists.boost.org Subject: Re: [Boost-users] XML Serialization Traits Question
"William Bardon"
wrote in message news:C73E689C9FCF884B9A550ECFADA0721C087D3E@exchange.cab-cds.org... I have read both the Boost Serialization online documentation and the archives of the Boost-Users mailing list looking for guidance, but I haven't found anything relevant. I see how to use BOOST_CLASS_TRACKING and BOOST_CLASS_IMPLEMENTATION to remove version tracking attributes from the XML tags. Usage of these macros does a lot more than remove attributes from the tags.
I want to go in the opposite direction. I notice that the class_id and version attributes only appear the first time an object of a particular class is serialized. I want to force the version attribute
to appear in every object's attribute list.
Do I need to derive a custom archive to do this?
yes
I have looked at the source code for serialization, but I have trouble
plowing through all of the macros, template expansions, and overloaded
functions to locate the specific part that controls whether class traits are stored as attributes in a particular XML tag.
I sympathize - its hard to follow. And I wrote it. Here are some hints:
a) look at demo_fast_archive.cpp to see a model of how one can derive from an existing archive. b) You'll want to derive from xml_oarchive_impl<...> to create my_xml_oarchive c) add a "save_override" function to my_xml_oarchive which replaces the "save_override" function in basic_xml_oarchive.ipp. Implement this using functions defined basic_xml_oarchive.ipp
Good luck -
Robert Ramey
Thanks in advance, Bill
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

William Bardon wrote:
Robert,
I forced a crude solution by defining a custom XML output archive and defining My_Archive::save_override(const nvp<T>&, int) as below. This would double the class information in some objects, so I also set the BOOST_CLASS_IMPLEMENTATION to object_serializable for my serialized classes. It is crude, but seems to give me the results I need.
Hmmm - crude but effective. I'm sure some would find that an apt description of the whole serialization library.
By examining the library's source code, I have determined that the tracking of class traits in serialization occurs in basic_oarchive_impl::save_object, defined in basic_oarchive.cpp. It uses the class cobject_type to track classes it has seen. Because basic_archive_impl and cobject_type are completely defined within basic_archive.cpp, the ability to customize XML attributes is limited.
I don't think this is a limitation.
Perhaps future versions of Serialization could look into making the XML optionally generate an XML schema for interoperation with other XML-based applications.
I considered that for a while. I only made the xml_?archive to satisfy those who thought it was necessary for the package to be useful. So I focused on the smallest, simplest, and "crudest" implementation which would pass the bar. I'm sort of amazed that that has been "good enough" so that user's have'nt seen it worthwhile to invest their own efforts to improve it. I see no obstacle on making an xml_[i/o]archive which would optionally dump an xml schema along with the xml data. I'm no xml expert so the details of what would be useful are not known to me. I don't think this would be a huge project for someone who really needs it. Good Luck. Robert Ramey
Thanks, Bill
\
participants (2)
-
Robert Ramey
-
William Bardon