From: Emil Dotchevski (emil_at_[hidden])
Date: 2007-11-16 05:09:57
> 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.
I was specifically addressing the design of the flyweight framework.
There is significant overlap between the flyweight domain and the
shared_ptr domain; in my opinion, policies are just as inappropriate
for flyweight as for shared_ptr (or just as appropriate in both cases,
depending on who you ask.)
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
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
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.
> > 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
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. :)
-- Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk