Emil Dotchevski ha escrito:
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.
I understand your point and I think it's respectable, but in the end your position is tantamount to banning policy-based classes, and with that I obviously cannot agree. You seem to object to using templates for one of the very purposes they were designed for: making the same code work for different types.
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.
Well, I think flyweight<> does not do exactly what you think in this respect: there's no need to *find out* which flyweight factory a given flyweight object is associated to because any flyweight<...> type has a unique factory of its own, identifiable at compile-time. So, the info on what factory to use when (de)serializing a flyweight does not travel across the archive.
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>.
Joaquín M López Muñoz Telefónica, Investigación y Desarrollo