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