
Hi, Can I suggest adding another example to: http://www.boost.org/libs/serialization/doc/special.html#objecttracking I had this code: void mycallback(const BigClass &BC){ const SomeData *d=BC.get_data(); ... archive & BOOST_SERIALIZATION_NVP(d); } My archive was smaller than intended and I discovered that the data only got saved the first time. XML version showed me it was using: object_id_reference. It turns out the fix was to dereference the pointer: archive & BOOST_SERIALIZATION_NVP(*d); That is an easy to write bug; I cannot see how the serialization library can catch it, so all I can think of is to make people aware of it in the docs. Also please mention "object_id_reference" in the objecttracking section of the docs, as that was the first thing I googled on and it got no useful hits. Darren

Hmm - what was wrong with the archive being smaller than you wanted? Since your argument is const, it should be the same value. dereferencing is not the same as serialization the pointer. In the second case a new object will be created when serialized. I would be surprised if dereferencing eliminated the copy. Finally, if you really want to write mulltiple copies of the same the item, the best way would be to mark objects of this type as "track_never" Robert Ramey Darren Cook wrote:
Hi, Can I suggest adding another example to: http://www.boost.org/libs/serialization/doc/special.html#objecttracking
I had this code:
void mycallback(const BigClass &BC){ const SomeData *d=BC.get_data(); ... archive & BOOST_SERIALIZATION_NVP(d); }
My archive was smaller than intended and I discovered that the data only got saved the first time. XML version showed me it was using: object_id_reference.
It turns out the fix was to dereference the pointer: archive & BOOST_SERIALIZATION_NVP(*d);
That is an easy to write bug; I cannot see how the serialization library can catch it, so all I can think of is to make people aware of it in the docs. Also please mention "object_id_reference" in the objecttracking section of the docs, as that was the first thing I googled on and it got no useful hits.
Darren
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost

Hmm - what was wrong with the archive being smaller than you wanted? Since your argument is const, it should be the same value.
It is const because BigClass::get_data() returns a const pointer to its internal data (which is not const). mycallback() is called repeatedly, as operations happen that change the data in BigClass.
dereferencing is not the same as serialization the pointer. In the second case a new object will be created when serialized. I would be surprised if dereferencing eliminated the copy.
No, it worked: I got the data I expected to be serialized. I realized after posting that doing this may be clearer: const SomeData &d=*BC.get_data(); (or get_data() returning a const reference in the first place, but BigClass works and I don't want to fiddle with it at the moment). Darren
Finally, if you really want to write mulltiple copies of the same the item, the best way would be to mark objects of this type as "track_never"
Robert Ramey
Darren Cook wrote:
Hi, Can I suggest adding another example to: http://www.boost.org/libs/serialization/doc/special.html#objecttracking
I had this code:
void mycallback(const BigClass &BC){ const SomeData *d=BC.get_data(); ... archive & BOOST_SERIALIZATION_NVP(d); }
My archive was smaller than intended and I discovered that the data only got saved the first time. XML version showed me it was using: object_id_reference.
It turns out the fix was to dereference the pointer: archive & BOOST_SERIALIZATION_NVP(*d);
That is an easy to write bug; I cannot see how the serialization library can catch it, so all I can think of is to make people aware of it in the docs. Also please mention "object_id_reference" in the objecttracking section of the docs, as that was the first thing I googled on and it got no useful hits.
Darren
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
participants (2)
-
Darren Cook
-
Robert Ramey