|
Boost Users : |
From: martin f krafft (madduck_at_[hidden])
Date: 2005-05-10 03:11:52
Consider a doubly-linked list. How do you serialise this?
The natural way would be to provide a serialize function such as:
template <class Archive>
void serialize(Archive& ar, unsigned int const)
{
ar & prev;
ar & next;
}
This, however, causes "pointer conflict" exception to be thrown,
because the next pointers are serialised before the actual list node
is serialised.
The following is an abridged scneario illustrating the same dilemma:
class Foo {
friend class boost::serialization::access;
template <typename AT> void serialize(AT& ar, unsigned int const)
{}
};
int main(void)
{
Foo x;
Foo *y = &x;
boost::archive::text_oarchive oa(std::cout);
oa & y; // serialise the pointer before the actual instance
oa & x; // throws boost::archive::archive_exception(pointer_conflict)
return 0;
}
I could come up with many more examples in which it is now granted
that an instance has been serialised by the time that a pointer to
that very instance needs to be serialised. How does
boost::serialization expect this challenge to be handled?
Note that I understand very well what pointer_conflict is all about.
I do wonder whether this protection is always necessary. Worse yet:
there seems to be no way to disable it; catching the
pointer_conflict skips over the serialisation of the instance.
Is the only way to deal with this to ensure that instances are
always saved first?
-- martin; (greetings from the heart of the sun.) \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net_at_madduck invalid/expired pgp subkeys? use subkeys.pgp.net as keyserver! spamtraps: madduck.bogus_at_[hidden] micro$oft encrypts your windows nt password when stored on a windows ce device. but if you look carefully at their encryption algorithm, they simply xor the password with "susageP", Pegasus spelled backwards. Pegasus is the code name of windows ce. this is so pathetic it's staggering.
Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net