$include_dir="/home/hyper-archives/boost-users/include"; include("$include_dir/msg-header.inc") ?>
From: gast128 (gast128_at_[hidden])
Date: 2007-08-13 11:08:00
Dear all,
I was trying to use the Boost Serialization library again, but I ran into a 
problem which cost me a full day. The Boost Serialization library is a very 
handy library, but often when I use it I run into problems which cost me days.
This time I try to serialize just 'track_never' objects. First of all the 
compiler firewall which is built in the library does not work when using the 
nvp macro:
void Foo()
{
   boost::archive::xml_oarchive oa(...)
 
   SomeStruct s;
   oa << s;                          // compile time error
   oa << BOOST_SERIALIZATION_NVP(s); //ok
} 
But this wasn't the real problem. I was looping to serialize non tracking 
objects: 
void Bla()
{
   boost::archive::xml_oarchive oa(...)
 
   for (int i = 0; i < 1000; ++i)
   {
      const SomeStruct s;
      oa << s;
   }
}
However the library did track them by pointer due to a previous request to 
serialize a pointer. It decides this on a call 
to 'basic_serializer::serialized_as_pointer' deep in the library.
struct SomeStructHolder
{
  SomeStructHolder() : m_p(NULL){}
  template <class Archive>
  void serialize(Archive& ar, const unsigned int /*version*/)
  {
     ar & BOOST_SERIALIZATION_NVP(m_p);
  }
  const SomeStruct* m_p;
};
somewhere else:
void Bla()
{
   boost::archive::xml_oarchive oa(...)
 
   const SomeStructHolder holder;
   oa << holder;
}
So this is again an unexpected property of the library. Maybe the ambition for 
automatic object tracking is too high, and specify it explicitly per class / 
per archiving operation would be more work for the user, but also clearer.
And still the original problem was too find out if Boost Serialization could 
also be used on a per demand loading of (value-)objects: in my problem the 
final storage can be potential bigger than computer memory, so I was wondering 
if objects could be loaded on demand (instead of all in once).
wkr,
me