In a normal PIMPL structure, the visible class is responsible for instantiating the private implementation class when the visible class is instantiated. However, when serialization is restoring objects, /it/ thinks it is responsible for instantiating all classes, including the private implementation classes of a PIMPL structure. Who wins? Do I end up with /two/ instances of the private implementation class, one of which is just hanging in mid-air? If you need a more solid background, here is what I'm doing: _Visible class header_: struct Foo_Private; class Foo { public: Foo(); . . ./other//stuff/ . . . . . . /data member-free serialization//code/ . . . private: *const std::unique_ptr< Foo_Private() > d_ptr**;* }; _Visible class code_: Foo::Foo() : *d_ptr(std::make_unique< Foo_Private >())* {...code to initialize Foo_Private data members...} _Private Implementation class header_: struct Foo_Private{ Foo_Private(); . . . /data member declarations/ . . . . . . /data member serialization code/ . . . }; Private implementation class has no code file. It is a header-only class. One alternative I thought of was to /not/ serialize the private implementation class, even though it contains all of the data member that need serializing. Instead, if the private class has data members, say, bar and baz, then the /visible/ class would have a serialize() function that "reached into" the private object using its d_ptr: template<class Archive> void serialize(Archive & ar, const unsigned int version) { ar & d_ptr->bar; ar & d_ptr->baz; } So, the visible class (which has no data members of its own) is serialized using data extracted from/inserted into the private class object. Would serialization-by-proxy work?