[boost] Re: Re:Serializable smart pointer

From: Andrei Alexandrescu (andrewalex_at_[hidden])
Date: 2002-04-18 23:16:48

"David B. Held" <dheld_at_[hidden]> wrote in message
news:a9n1el$j4u$1_at_main.gmane.org...
> Another thing I'd like to see is what I call a serializable smart
pointer.
> This is just a smart pointer that stores either a pointer or an int,
so it's
> like a variant.  I store object IDs, which is what I would load into
the
> pointer on initialization, and then do a fixup after all relevant
objects
> are loaded.  Right now, I do this in a wrapper I wrote, which may
> be the preferred way to do it.  But it seems to me a bit more
elegant
> to do it in the smart pointer itself.

First, let me thank you for your message that I just read about
starting the boostification of Loki::SmartPtr.

The problem you bring is a good example of two things: (1) that
SmartPtr offers quite some flexibility; (2) how a design can be nicely
built from pre-existing parts in a elegant way.

I think a viable design could look like this: You can write a custom
StoragePolicy for your pointer. In it, instead of a pointer, you store
a Variant object (or a simple tagged union built by hand. The size
overhead is about the same.) In your GetImpl and GetImplRef functions,
you check whether you had initialized the pointer. If not, you refer
to an externally defined Loki::ObjectFactory<int, MyObject> that maps
integers to your polymorphic types. Likely, the factory would be
hosted by a Loki::SingletonHolder.

> From what I can tell,
> it isn't, since it would require a bit more interface than SmartPtr
has
> (one would need a way to store and fetch two different types).

I think you are right, and I believe the design of SmartPtr might be
enhanced with a template constructor that allows SmarPtr to accept
whatever type the StoragePolicy is willing to take. More so, I believe
that not providing that constructor is a flaw in SmartPtr's design;
thanks for pointing it out.

Andrei