More about http://svn.boost.org/svn/boost/sandbox/flyweight/libs/flyweight/doc/referenc... I don't understand the source of the complexity at the flyweight<> level. A "naive" flyweight<> could look like: template<class T, class F = default_factory> class flyweight { typedef typename F::handle_type handle_type; handle_type handle_; public: flyweight( ... args ): handle_( F::insert( T( args... ) ) ) {} T const& get() const { return F::value( handle_ ); } }; It seems to me that this provides the same amount of expressive power as the current interface. Locking/tracking/holding can be made parameters of the Factory if so desired, and a factory_core<F',L,T,H> template may be provided as a convenience in a separate header, but in the majority of the cases the user will never need it. In fact flyweight<> is already implemented in a similar way, it uses a flyweight_core<> class as F. Note that the above simpler flyweight<> allows me to pass the aforementioned template<class T> struct sp_factory { typedef boost::shared_ptr<T const> handle_type; static handle_type insert( T const & t ) { return handle_type( new T( t ) ); } static T const & entry( handle_type p ) { return *p; } }; as F; there's no need to invent a locking policy, a tracking policy, a holder, or a stateful factory.