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@madduck invalid/expired pgp subkeys? use subkeys.pgp.net as keyserver! spamtraps: madduck.bogus@madduck.net 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.