Re: [boost] Formal review request: Flyweight

From: Joaquin M Lopez Munoz (joaquin_at_[hidden])
Date: 2007-11-16 11:34:20

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