Re: [boost] [flyweight] some minor comments

From: Joaquin M Lopez Munoz (joaquin_at_[hidden])
Date: 2007-12-14 14:10:57

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