Emil Dotchevski <emil <at> revergestudios.com> writes:
I'll make one last attempt... :)
Let's say I have a vector< flyweight<string> > container. Let's also assume that, based on the value of the stored string object, I want to allocate the flyweight differently. No problem, right? All I have to do is write a custom factory, and change my container's value type: vector< flyweight<string,tag<my_factory> > >. So, my_factory inspects the string value passed to it, and uses the appropriate allocation strategy.
But what if I can't hard-code the factory behavior? What if I want to allow user code to choose how each individual flyweight<string> is to be allocated?
There are many operations on flyweight<string> that have nothing to do with how it was allocated, yet this design couples them physically with the factory.
I have two observations regarding this: 1. I think the local_flyweight variation I presented a couple of posts ago addresses this use case. Do you see it otherwise? 2. Anyway, what do you want such a fine control over factories (no irony intended)? After all, having the flyweight value stored in one factory or another is a transparent aspect for most of flyweight<> use interface. The primary purpose of flyweight is to provide a replacement for const T that it's space efficient, no factories involved in this rationale. Think of the factory in flyweight<> as playing a similar role as the allocator in std::basic_string<>. Have you ever felt the need to have two std::string's using a different allocator object?
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
I realize that. But, *if* we come up with a "proper" serialization of shared_ptr (which is necessary anyway), and *if* the design of flyweight<> is altered like I am suggesting, then flyweight<> becomes (almost) trivial to implement. :)
I haven't thought about how serialization of a potential local_flyweight<> would be, but it looks much more involved than pure flyweight<>, where the factory isn't actually serialized at all. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo