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:
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
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk