JOAQUIN LOPEZ MU?Z skrev:

----- Mensaje original ----- De: Thorsten Ottosen <thorsten.ottosen@dezide.com> Fecha: Jueves, Diciembre 13, 2007 9:55 pm Asunto: [boost] [flyweight] some minor comments Para: boost@lists.boost.org

...

Hi Joaquín,

Your docs looks real nice.

Thank you! I hope you can participate in the upcoming review.

Could be.

...

But I have the following suggestion:

- make it possible to use boost::flyweight<T> without the use of factories. The number of elements I want to create is fairly low, and so does not justify having a seperate container "flying" around.

I'n not sure how flyweight could possibly work without a factory to keep the common values. Can you elaborate the scenario you have in mind?

I would use it as a lightweight and more convenient replacement for boost::shared_ptr<const T>. In my application I might have < 50 objects that needs to by flyweights. They are almost never identical, and if they are, the memory occupied by the factory would probably be much larger than that of duplication. Also, the forced use of a factory places many extra requirements on T, operator== and hash function, which I consider limiting for the immediate usability of the library.

...

PS: what a shame we can't overload operator.() in C++

A pity indeed. Stroustrup discusses the matter in his "The Design and Evolution of C++" and he himself does not have a strong opinion against/in favor of such feature.

The current C++0x effort has been discussing it briefly, but it never got much attention AFAICT, sadly. A few papers discuss them: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2200.pdf "With one notable exception for the two dot operators which we currently believe cause more trouble than they fix." http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1671.pdf has a longer discussion. Btw, I couldn't remember from the code if you provided operator->() in this manner: const T* operator->() const; ? If not, maybe it would be worth adding. -Thorsten

Joaquin M Lopez Munoz skrev:

Thorsten Ottosen <thorsten.ottosen <at> dezide.com> writes:

...

I would use it as a lightweight and more convenient replacement for boost::shared_ptr<const T>.

In my application I might have < 50 objects that needs to by flyweights. They are almost never identical, and if they are, the memory occupied by the factory would probably be much larger than that of duplication.

Well, then you might not need using the flyweight idiom after all...

Well, it's lower overhead (if no factory and forwarding constructors/operations makes it a better choice than shared_ptrconst T>. -Thorsten

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.

----- 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

Peter,

Thorsten Ottosen:

...

Joaquin M Lopez Munoz skrev:

...

Thorsten Ottosen <thorsten.ottosen <at> dezide.com> writes:

...

I would use it as a lightweight and more convenient replacement for boost::shared_ptr<const T>.

In my application I might have < 50 objects that needs to by flyweights. They are almost never identical, and if they are, the memory occupied by the factory would probably be much larger than that of duplication. Well, then you might not need using the flyweight idiom after all... Well, it's lower overhead (if no factory and forwarding constructors/operations makes it a better choice than shared_ptrconst T>.

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2351.htm describes make_shared(). Any reason you haven't added a version to trunk? -Thorsten

Hi, When ignoring the metaprogramming part, an operator. is also interesting for generic proxies and mocks. It does give a few bumps along the road in terms of "what if operator. invokes operator." or "what if the returned function + object again have an operator.", but I think that's possible. The main problems are 1. people assume you want an operator. that does what operator-> does but with a reference 2. people stubbornly insist this isn't practical or needed so I doubt you'll be able to get anywhere. I hope so though, as I would like a generic mock / proxy class. Regards and good luck, Peter On 17/12/2007, Mathias Gaunard <mathias.gaunard@ens-lyon.org> wrote:

Sorry for this off-topic message, but I thought discussing overloading of operator. could be interesting.

Thorsten Ottosen wrote:

...

PS: what a shame we can't overload operator.() in C++

I think most of the proposals that have been made are quite wrong in their approach. They usually simply forward operator. to a reference.

While this is enough for things that only require forwarding, (like flyweight does) it is not a generic solution. It cannot be used with variant, for example.

First, what is the type of the right operand of operator. ? A name, a compile-time string, plus some eventual arguments if it's a member function call. mpl::vector_c<char, ....> is quite what we need.

Then, we need the ability to call a member from its name, and that requires some kind of compile-time reflection. Here again, mpl helps to build the structure of the reflection information.

template <typename T> struct reflection { };

template<> struct reflection<MyClass> { typedef mpl::map< mpl::pair< mpl::vector_c<char, 'm', 'e', 'm', 'b', 'e', 'r', '1'>, a_function_object_type /* the type could contain additional information about the available signatures */ >, .... > members;

typedef .... typedefs; typedef .... static_members; };

(all public members could be listed, including inherited ones)

This solution would be best, but since it is meta-programming intensive, requires usage of type containers, and is not easy to code with, I doubt the standard will want to adopt it.

_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost