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