The basic difficulty here stems from the decision to use serialization to save/load part of the data structure of the program. That is - some but not all of the shared_ptr. When loading, the serialization will make a whole new set which are distince from the original ones. If you want to then match the recently loaded ones with the existing ones, then there is some work to be done. This is how I understand your situation - I'm not sure my understanding is correct - but there it is. So when asked how to handle the "matching" - my thought is to say - wait a minute - why are we in this situation in the first place? Then re-think the design. Currently after loading and matching to the other pointers in the program an getting things all working is going to be an error prone process. I'm sure its doable, and maybe there is no other options. But when I see a situation where I have to insert some very elaborate code to address the fact the my other components don't quite fit together, I'm thinking that maybe its a good time to step back an review how I got to this situation in the first place. One big idea would be not use the serialization library to create new objects but just make sure they created a head of time. This is the essence of my suggestion about using references rather than pointers. When using pointers for this purpose your class might look something like class a { // side note : weak_ptr would probably be better here const shared_ptr<x> ptr; ... template<class Archive> void serialize(Archive &ar, const unsigned version){ ar >> *(ptr.get()); // don't create new object } a(shared_ptr<x> p) : ptr(p) {} }; which would be pretty much equivalent to class a { x & ref; template<class Archive> void serialize(Archive &ar, const unsigned version){ ar >> ref; // don't create new object } a(const x & r) : ref(r) {} }; In both cases, the object creation/ managment facility of the serializaition library is avoided. Keep the object management within your own application. Robert Ramey