Re: [boost] [flyweight] some minor comments

From: Thorsten Ottosen (thorsten.ottosen_at_[hidden])
Date: 2007-12-14 10:01:54

JOAQUIN LOPEZ MU?Z skrev:
> ----- Mensaje original -----
> De: Thorsten Ottosen <thorsten.ottosen_at_[hidden]>
> Fecha: Jueves, Diciembre 13, 2007 9:55 pm
> Asunto: [boost] [flyweight] some minor comments
> Para: boost_at_[hidden]
> 
>> 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