Boost logo

Boost :

From: Hall, Rod (rhall_at_[hidden])
Date: 2002-09-11 13:26:42


There are two issues with the archiving of polymorphic objects through a
base class that I find problematic in the current design.

1. That no base class can contain pure virtual functions.
2. That the most derived class must be registered.

It's a common (encouraged?) practise to manipulate derived classes through
interface classes, these interfaces are usually abstract so issue 1 must
break half of the code in existance :)

It's also common to have two classes, A and B, where class A has a container
of pointers to objects of type B. Class B is abstract but has a hierarchy
derived from it.

When class A comes to archive the contents of the (possibly not STL)
container it has no way of knowing the dynamic types of the pointers it's
storing (or loading, were storage possible).

The various serialization approaches I've looked at lead me to conclude that
deriving from a common ancestor and having intrusive serialization support
code/data may be a constraint but only by using some mechanism that can
register and create serializable objects with proprietary extended RTTI can
you make archives self-describing within a given class framework.
Serialization seems to need a decent RTTI/reflection capability, C++ doesn't
have one.



This communication contains confidential information intended solely for the use of the individual/s and/or entity or entities to whom it was intended to be addressed.  If you are not the intended recipient, be aware that any disclosure, copying, distribution, or use of the contents of this transmission is prohibited.  If you have received this communication in error, please contact the sender immediately, delete this communication from your system, and do not disclose its contents to any third party, or use its contents.  Any opinions expressed are solely those of the author and do not necessarily represent those of Orchestream Ltd or its group of companies unless otherwise specifically stated.

Boost list run by bdawes at, gregod at, cpdaniel at, john at