I just read a few pages of the documentation and I think I understand the problem this library addresses. Since the library is designed to be like a drop-in replacement for immutable shared objects, there are similarities with shared_ptr: flyweight<T> is designed to be a drop-in replacement for T const, whereas shared_ptr<T> is a drop-in replacement for T *. Even issues related to serialization and factories are similar between shared_ptr<T> and flyweight<T>. I am pointing out the similarities because the flyweight framework lacks a very important property of shared_ptr, which I think is directly applicable, and it has to do with the way flyweight<T> is configured. This is how two flyweight<string> objects can be configured to use different pools: struct name_tag1{}; typedef flyweight<std::string,tag<name_tag1> > str1_t; struct name_tag2{}; typedef flyweight<std::string,tag<name_tag2> > str2_t; The problem is that now str1_t and str2_t are distinct types in the type system, yet they are identical semantically. Suppose I have a function that takes a flyweight string like this: void foo( flyweight<std::string> const & s ); Even if implicit conversions between different configurations of flyweight<std::string> exists, calling foo with str1_t or str2_t would create unwanted temporary objects. Besides, such conversions will create a default-configured flyweight<std::string>, which is not desirable. The only option I would have is to make foo a template which is unfortunate because it would increase physical coupling unnecessarily. Compare this with the way users supply custom allocators to shared_ptr: http://www.boost.org/libs/smart_ptr/shared_ptr.htm#allocator_constructor Two shared_ptr<T> objects that use different allocators, once initialized, are indistinguishable from each other because they are of the same type, shared_ptr<T>. I would like flyweight<T> configuration to work similarly. -- Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode