----- Mensaje original ----- De: Peter Dimov <pdimov@pdimov.com> Fecha: Domingo, Diciembre 16, 2007 10:09 pm Asunto: Re: [boost] [flyweight] some minor comments Para: boost@lists.boost.org
More about
http://svn.boost.org/svn/boost/sandbox/flyweight/libs/ flyweight/doc/reference/flyweight.html#flyweight
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.
Well, the very fine-grained policy decomposition of flyweight<> relies on the assumption that users will need to control the aspects exposed. With the predefined components already provided by the lib, there are 24 different configurations, each one meaningful: an user might want to use a set-based factory for types with problematic hashing, another is happy with hashed-based lookup but does not want locking (she works in a single-threaded environment), etc. If the user doesn't need to change any of the defaults, then she can include boost/flyweight.hpp and use flyweight without even needing to know about factories, tracking and such --this is in fact what the tutorial recommends.
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 sp_factory[...] as F; there's no need to invent a locking policy, a tracking policy, a holder, or a stateful factory.
If I understand your point correctly, you suggest turning flyweight into a single-policy class: template<typename T,typename F=flyweight_core<...> > class flyweight; and moving the fine-grained policies into flyweight_core, right? Well, this is certainly feasible and nicely accommodates global core replacements as the one you provide, but to me this is not a simplification of the design, it's merely allowing for an additional customization point. It can be included if deemed interesting, of course. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo