[serialization] polymorphic archive destructor slicing

In boost-1.33.1 and before, and still in boost-cvs, the base polymorphic archive classes (polymorphic_iarchive, polymorphic_oarchive) have non-virtual (default) destructors. The typical usage pattern for these types is to construct a derived class and return the base pointer to clients, who only know that the archive is a polymorphic archive, and not the specific derived class. This results in the client not being able to correctly delete the archive, even though the destructor is accessible (and so, easily invoked). I think that the right solution here is for the base polymorphic archive classes to define a public virtual destructor.

Kim Barrett wrote:
In boost-1.33.1 and before, and still in boost-cvs, the base polymorphic archive classes (polymorphic_iarchive, polymorphic_oarchive) have non-virtual (default) destructors. The typical usage pattern for these types is to construct a derived class and return the base pointer to clients, who only know that the archive is a polymorphic archive, and not the specific derived class. This results in the client not being able to correctly delete the archive, even though the destructor is accessible (and so, easily invoked). I think that the right solution here is for the base polymorphic archive classes to define a public virtual destructor.
I doubt its a problem in practice as the derived archive is usually constructed on the stack and thus gets destroyed automatically when it goes out of scope. Never the less, it looks to me like you're correct so I'll make the change in the CVS Head Robert Ramey

At 5:48 PM -0700 9/1/06, Robert Ramey wrote:
I doubt its a problem in practice as the derived archive is usually constructed on the stack and thus gets destroyed automatically when it goes out of scope.
I got bit by this because I've got several "factory" functions that make the various kinds of polymorphic archives that I'm using, all returning a pointer to the appropriately directioned base polymorphic archive. That way, only that one translation unit ever sees any of the more specific archive headers, and it is included in a shared library that lots of different programs use. The workaround was to change my factory functions to return a shared_ptr to the new archive (with the shared_ptr's deleter knowing the precise archive type), which was probably an improvement anyway.
Never the less, it looks to me like you're correct so I'll make the change in the CVS Head
Thanks.
participants (2)
-
Kim Barrett
-
Robert Ramey