[serialization] serialization of pointers to primitive types?

The following test program:
#include

Joaquín Mª López Muñoz wrote:
The following test program:
#include
#include <sstream> int main() { int x=0; int* const px=&x; std::ostringstream oss; boost::archive::text_oarchive oa(oss); oa<
return 0; } .... I've checked the same snippet against Boost 1.33.1, CVS HEAD and RC_1_34_0, using other primitive types like std::string, same problem always. Same problem also for the loading counterpart. When the pointed-to type is not primitive, though, everything works fine, regardless of whether the type has intrusive or non intrusive serialization support.
I am sure I'm doing something really stupid here, but I've been banging my head against this several hours. Some clue greatly appreciated.
This never worked, I think. The problem is that if you're saving pointers, you need to check if you've already saved that pointer, so that on loading, you don't get two pointers to to ints, as opposed to two pointers to a single int, as it should be. This "tracking" requires runtime map, and I believe Robert decided that maintaining such map for primitive type can be too expensive. I'm not sure how valid that point it, not how many hidden stones there are in enabling primitive types to be tracked. - Volodya

Serialization of pointers to primitive data types is prohibited. I'm pretty sure this is mentioned in the documentation. ( don't have the exact reference handy) - and it has been noted a couple of times. The reason is that doing this would result in ALL usages of that type being tracked - which is probably a heck of a lot more than the user had in mind. The way to serialize pointer to primitives (serialization_level::prmitive) is to use BOOST_STRONG_TYPEDEF to define a new type and specify serialization function for it. This won't work for std::string so you'll have to make a trivial derivation of std::string if you want to serialize a pointer to a std::string. Robert Ramey Joaquín Mª López Muñoz wrote:
The following test program:
#include
#include <sstream> int main() { int x=0; int* const px=&x; std::ostringstream oss; boost::archive::text_oarchive oa(oss); oa<
return 0; }
produces this error in MSVC++ 6.0:
...boost/serialization/access.hpp(109) : error C2228: left of '.serialize' must have class/struct/union type ...boost/serialization/serialization.hpp(81) : see reference to function template instantiation 'void __cdecl boost::serialization::access::serialize( class boost::archive::text_oarchive &,int &,const unsigned int)' being compiled
and the following error in GCC 3.2:
...boost/serialization/access.hpp: In static member function `static void boost::serialization::access::serialize(Archive&, T&, unsigned int) [with Archive = boost::archive::text_oarchive, T = int]': ... ...boost/serialization/access.hpp:109: request for member `serialize' in `t', which is of non-aggregate type `int'
I've checked the same snippet against Boost 1.33.1, CVS HEAD and RC_1_34_0, using other primitive types like std::string, same problem always. Same problem also for the loading counterpart. When the pointed-to type is not primitive, though, everything works fine, regardless of whether the type has intrusive or non intrusive serialization support.
I am sure I'm doing something really stupid here, but I've been banging my head against this several hours. Some clue greatly appreciated.
Thank you,
Joaquín Mª López Muñoz Telefónica, Investigación y Desarrollo

I've been looking at this issue. It turns out that the connection of
serialization
of pointers to primitives to tracking was an unintentional side-effect
of the implementation. When it started to happen I just assumed it
was an intentional decision. Looking through the code - it doesn't look
trivial to address. Wouldn't the following modification to your test
program address your concern?
Robert Ramey
#include

I've looked a little more at this. It is addressable in a convenient way. However, without additional effort, the best fix will obsolete existing archives. So its a little more effort than meets the eye. Robert Ramey
participants (3)
-
Joaquín Mª López Muñoz
-
Robert Ramey
-
Vladimir Prus