Robert Ramey wrote:

This should work - How is your case different that test_cycle.cpp ?

I can't find test_cycle.cpp unfortunately, so I don't know. See my example below.

The pointer conflict means that something has been serializaed as first as a pointer then as an object. Normally this should be easily avoidable. This is flagged as an error because the de-serialization would be a problem. First the deserialization of a pointer creates an object - next the object itself is re-loaded - but now we have two objects when we started with one.

I see what you mean, but I fail how to see a convenient way to avoid it without changing all containers so that they have pointers instead of objects or something like that. Is perhaps BOOST_CLASS_TRACKING the key? --- #include <vector> #include <fstream> #include #include class A { friend class boost::serialization::access; public: A() : next(0) { }; A* next; private: template<class Archive> void serialize(Archive & ar, const unsigned int){ ar & BOOST_SERIALIZATION_NVP(next); } }; int main() { std::ofstream ofs("test_of_serialization.dat"); boost::archive::xml_oarchive oa(ofs); std::vector<A> a1(4); a1[0].next = &a1[0]; a1[1].next = &a1[1]; a1[2].next = &a1[2]; a1[3].next = &a1[3]; oa << BOOST_SERIALIZATION_NVP(a1); // everything worked fine with a1... std::vector a2(4); a2[0] = new A; a2[1] = new A; a2[2] = new A; a2[3] = new A; a2[0]->next = a2[1]; a2[1]->next = a2[2]; a2[2]->next = a2[3]; a2[3]->next = a2[0]; oa << BOOST_SERIALIZATION_NVP(a2); // everything worked fine with a2... std::vector<A> a3(4); a3[0].next = &a3[1]; a3[1].next = &a3[2]; a3[2].next = &a3[3]; a3[3].next = &a3[0]; // but this throws "pointer conflict" exception oa << BOOST_SERIALIZATION_NVP(a3); } --- // Henrik Jacobsson

Robert Ramey

Henrik Jacobsson wrote:

...

Hi!

I want to serialize objects that link to each other through pointers, like a linked list, but in this case a more complex graph with several different classes and proxies (a graph which can contain loops and and null-pointers).

But I get the "pointer conflict" exception since the serialization discovers that an object have been serialized once before through its pointer. The contents should be serialized/deserialized only once, and then the pointers should just be kept consistent.

An alternative is of course to replace all the pointers with indeces which are memory-independent. But that's a messy affair.

In the copy constructor I solved something similar through a map which mapped from the old pointers to the newly allocated ones, so that they could be properly replaced. Is something like this hidden somewhere in the lib?

Any suggestions?

Best regards, Henrik Jacobsson

_______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users

I stand corrected. test_cyclic_ptr doesn't quite test what I thought it did. So cyclic objects can't be serialized. cyclic object pointers can be serialized with no special effort. Robert Ramey

also sprach martin f krafft [2005.05.12.1219 +0200]:

Well, except for serialising and deserialising only pointers. So now I have to figure out how to prevent wads of memory "leaks" trying to determine when to delete those pointers again.

This makes me think: has anyone successfully plugged in your own allocator and/or factory into Robert's serialization framework? -- martin; (greetings from the heart of the sun.) \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck invalid/expired pgp subkeys? use subkeys.pgp.net as keyserver! spamtraps: madduck.bogus@madduck.net "self-denial is the shining sore on the leprous body of christianity." -- oscar wilde

also sprach Robert Ramey [2005.05.12.1823 +0200]:

Now you're making me dizzy.

No, really. I need to use a pool allocator for my objects. Are you telling me I cannot? -- martin; (greetings from the heart of the sun.) \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck invalid/expired pgp subkeys? use subkeys.pgp.net as keyserver! spamtraps: madduck.bogus@madduck.net after you install windows xp, you have the option to create user accounts. if you create user accounts, by default, they will have an account type of administrator with no password. way to go!

also sprach Robert Ramey [2005.05.13.0346 +0200]:

No, I'm just saying I don't think anyone has done it. Honestly, I don't know if I made any accidental assumptions regarding allocators in the package. I would be please to see someone try this and report any problems. Then we could add a test and have one more thing certified as working.

Ha! I can't even find the place where space is allocated. It's not *_construct_data, as here the space already exists. Could you point me to some place where the allocation is being done during deserialisation of a pointer? -- martin; (greetings from the heart of the sun.) \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck invalid/expired pgp subkeys? use subkeys.pgp.net as keyserver! spamtraps: madduck.bogus@madduck.net when compared to windoze, unix is an operating system.

Henrik Jacobsson wrote:

...

cyclic objects can't be serialized. cyclic object pointers can be serialized with no special effort.

A simple, and probably naive, idea... Since pointers mean no problems and objects do, would it not be possible to have an option "serialize_object_as_pointer" and for containers "serialize_members_as_pointers" in the library, as a means to circumvent this? That way one would not have to change the implementation of all containers of cyclic objects into containers of pointers...

I don't think this would work for a couple of reasons - mainly that if you save objects that arn't pointers, the loader would create pointers and you wouldn't have the same thing that you started with.

Alternatively, or additionally, within the cyclic object themselves, it would be nice if it was possible to serialize the pointer without serializing its contents, i.e. creating only an index in the archive, making it up to the user to make sure that the object is later serialized with that index to adress it.

That's more or less how the serialization of pointers works now - and that's why it DOES work. Robert Ramey

martin f krafft wrote:

...

Alternatively, or additionally, within the cyclic object themselves, it would be nice if it was possible to serialize the pointer without serializing its contents, i.e. creating only an index in the archive, making it up to the user to make sure that the object is later serialized with that index to adress it.

That's more or less how the serialization of pointers works now - and that's why it DOES work.

If I end up not serialising the pointee object, the framework does serialise it automatically, right? That is to say: { A a; a.x = 5; ar << &a; } //... A *b ar >> b; assert(b->x == 5) should work just fine, right? That should work. for symetry I would have written { const A *a = new A(5); ... ar << a; ... A *new_a; ... ar >> new_a .. assert(*a == *new_a); } Note the slightly trick usage of const in this example which has been the subject of recent posts and is explained in the manual section describing tracking. Robert Ramey