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 );
If you have two systems that internally use std::string to store strings, they could conceivably communicate in terms of a char const * interface; but the fact that you can strip the std::string semantics, doesn't mean that you always want to. Similarly, yes, you can pass a flyweight<std::string> as an immutable std::string, but in doing so you're getting rid of the flyweight semantics. Sometimes this is exactly what you want, and sometimes it isn't. In the latter case you have the problem I outlined.
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?
The one that does not exist (yet) :) Let's say you have two shared_ptr<foo> objects, pa and pb, that point to different foo objects. How do you serialize them? Consider that they may have been created by different factories and so at write time you need to save that information so that at read time you know which factory to use for pa and for pb. If I understand correctly what flyweight factories are, and how flyweight is serialized, it solves a very similar problem. So what I mean is, perhaps this problem can be solved independently of flyweight and applied to both flyweight and shared_ptr. Even better (in my opinion), the problem can be solved for shared_ptr, and then flyweight<T> could be implemented over shared_ptr<T>. -- Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode