Re: [boost] Formal review request: Flyweight

From: Joaquín Mª López Muñoz (joaquin_at_[hidden])
Date: 2007-11-15 03:23:59

Emil Dotchevski ha escrito:

[...]

> If we look at shared_ptr again, there are competing, policy-based
> smart pointer designs, but they all lack the ability to work with
> incomplete types. For anything to be a drop-in replacement for T *, it
> must work with incomplete types. In other words, a policy-based smart
> pointer design can be "smart", but it wouldn't be much of a "pointer".
>
> Similarly, if flyweight<std::string> aims to be a drop-in replacement
> for an immutable std::string, it should have the key properties of
> std::strings. For example:
>
> std::string s1;
> std::string s2;
>
> Now I want to make use of flyweight, so I write:
>
> flyweight<std::string,tag<tag_name> > s1;
> flyweight<std::string,tag<tag_ip> > s2;
>
> I started with two objects of the same type, and ended up with two
> objects of different types. As a user, I have two options: to get
> unwanted temporaries at various points in my code, or to templatize
> sections of my code to avoid them.
>
> Either choice would be a show-stopper for me.

As far as I can see, this is a re-statement of your original complaint. You
can avoid proliferation of tagged flyweights by using the (non-existent yet)
local_flyweight, which defers domain selection to run-time. Is this not a
solution to your concern?

Another possibility, and this might be more likeable to you, is to take advantage
of the implicit conversion from flyweight<T> to const T&, and instead of
having

void foo( flyweight<std::string> const & s );

write

void foo( std::string const & s );

which will work with any flyweight of std::string, regardless of its being tagged
or not and the different configuration policies used. No temporaries are created.
And without templatizing anything. Is this more in line with what you have in mind?

> Also, shared_ptr needs proper factory support to compliment
> serialization of shared_ptr objects, which is the same stuff needed to
> implement flyweight.

I don't understand this. What factory support for shared_ptr are you referring
to?

> I think that removing the policies from flyweight
> will make it possible to implement the factories and the serialization
> support for shared_ptr directly, making the flyweight class template a
> thin wrapper over shared_ptr, and thus much lighter Boost library.

Again I don't get it. What is the relation between removing policies from
flyweight<> and implementing serialization support for shared_ptr?
Could you please elaborate your point? Thank you!

Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo