Re: [boost] [flyweight] some minor comments

From: JOAQUIN LOPEZ MU?Z (joaquin_at_[hidden])
Date: 2007-12-16 16:52:05

----- Mensaje original -----
De: Peter Dimov <pdimov_at_[hidden]>
Fecha: Domingo, Diciembre 16, 2007 10:09 pm
Asunto: Re: [boost] [flyweight] some minor comments
Para: boost_at_[hidden]

> 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