Re: [boost] Formal review request: Flyweight

From: Emil Dotchevski (emil_at_[hidden])
Date: 2007-11-14 21:59:02

> Why implementing this in a different class than flyweight<>
> itself? The reason is the value objects of local_flyweight<>
> (the elements stored at the flyweight factory, which contain
> the shared data as well as some bookkeeping info) must have
> a pointer to its context, whereas in the case of flyweight<>
> this context is associated to the type itself, thus saving
> us a pointer per value.

If we look at shared_ptr again, there are competing, policy-based
smart pointer designs, but they all lack the ability to work with
incomplete types. For anything to be a drop-in replacement for T *, it
must work with incomplete types. In other words, a policy-based smart
pointer design can be "smart", but it wouldn't be much of a "pointer".

Similarly, if flyweight<std::string> aims to be a drop-in replacement
for an immutable std::string, it should have the key properties of
std::strings. For example:

std::string s1;
std::string s2;

Now I want to make use of flyweight, so I write:

flyweight<std::string,tag<tag_name> > s1;
flyweight<std::string,tag<tag_ip> > s2;

I started with two objects of the same type, and ended up with two
objects of different types. As a user, I have two options: to get
unwanted temporaries at various points in my code, or to templatize
sections of my code to avoid them.

Either choice would be a show-stopper for me.

Also, shared_ptr needs proper factory support to compliment
serialization of shared_ptr objects, which is the same stuff needed to
implement flyweight. I think that removing the policies from flyweight
will make it possible to implement the factories and the serialization
support for shared_ptr directly, making the flyweight class template a
thin wrapper over shared_ptr, and thus much lighter Boost library.

-- 
Emil Dotchevski
Reverge Studios, Inc.
http://www.revergestudios.com/reblog/index.php?n=ReCode