Thorsten Ottosen <thorsten.ottosen <at> dezide.com> writes:
JOAQUIN LOPEZ MU?Z skrev:
----- Mensaje original ----- De: Thorsten Ottosen <thorsten.ottosen <at> dezide.com> Fecha: Jueves, Diciembre 13, 2007 9:55 pm Asunto: [boost] [flyweight] some minor comments Para: boost <at> lists.boost.org
[...]
- 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.
Well, then you might not need using the flyweight idiom after all... Not that it can't be done (it could with a custom "null" factory and a minor technical change), but it seems to defeat the whole point of the library. Note that not all value duplications would be detected and taken advantage of: no_factory_flyweight<std::string> str1="goddag"; no_factory_flyweight<std::string> str2="goddag"; no_factory_flyweight<std::string> str3=str2; str1 and str2 would hold pointers to different values, since you've got no factory to look for duplicates; str1 and str2 are completely disconnected, so to say. str2 and str3, on the other hand, would share their value.
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.
These requirements are imposed by the special kind of factory used by default--a hashed one. Using some other factory, like for instance set factory (http://tinyurl.com/2oxpvr ), calls for different requirements, in the case of set_factory that T have operator<. One thing's true, no matter what kind of factory you use T has to have some way to be compared for equivalence of values.
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.
No, I don't provide that, and I also think it's something worth adding. Tobias Schwinger also suggested this thing on offlist discussions with me. The only thing that puts me off a little is that this would clash, in a conceptual sense, with the current interface for getting a ref to T. In all, we'd have const T& get()const; operator const T&()const; const T* operator->()const; which is like a mix of Boost.Ref and Boost.Optional access semantics. It looks odd that a class behaves as a value and as a pointer at the same time. But of course there's nothing wrong about having both except the unusualness of it. Anyway, this is something I defintely will ask to be discussed upon during the review. Thank you, Joaquín M López Muñoz Telefónica, Investigación y Desarrollo