----- Mensaje original ----- De: Peter Dimov <pdimov@pdimov.com> Fecha: Domingo, Diciembre 16, 2007 8:27 pm Asunto: Re: [boost] [flyweight] some minor comments Para: boost@lists.boost.org
Thorsten Ottosen:
Well, it's lower overhead (if no factory and forwarding constructors/operations makes it a better choice than shared_ptrconst T>.
It might be possible to do this using a custom factory along the lines of:
template<class T> struct sp_factory { typedef boost::shared_ptr<T const> handle_type;
handle_type insert( T const & t ) { return handle_type( new T( t ) ); } void erase( handle_type ) {} T const & entry( handle_type p ) { return *p; } };
This approach would work (except for a technical issue I comment later) but it's overkill because it provides its own tracking, which is already taken care of by the Tracking policy. One would use then in conjunction with the no_tracking and no_locking policies, sort of like this: template<class T> using no_factory_flyweight= flyweight<T,sp_factory<_1,_2>,no_tracking,no_locking>; An alternative would be to provide an even simpler factory: template<typename Entry,typename Value> struct trivial_factory { typedef const Entry* handle_type; handle_type insert(const Entry& x){return new Entry(x);} void erase(handle_type p){delete p;} const Entry& entry(handle_type p){delete p;} }; // default tracking is ref_counted template<class T> using no_factory_flyweight= flyweight<T,trivial_factory<_1,_2>,no_locking>; Either of these two alternatives *almost* works, but for a detail: equality of flyweight objects is defined in terms of equality of reference, i.e. x==y iff &x.get()==&y.get(). sp_factory (and trivial_factory) interpret every value as distinct for any other: no_factory_flyweight<std:string> x("hello"), y("hello"); assert(x!=y); //assertion passes which results in no value sharing, except when a flyweight is copied from another. Nothing wrong with this as long as it is known and accepted, of course.
but there's no way to tell from the documentation; it never describes how the Factory template parameter is actually used. [...] As I read it, a flyweight<> can ignore all of its template parameters beyond T and still conform to its spec, which is probably not what's intended.
I tried to be more descriptive than prescriptive so as to not overspecifiy the internals of flyweight<>, but you're right the formal connection between flyweight<> and its template arguments has to be given. I'll try to improve this part of the reference. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo