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 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.
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. :) -- Emil Dotchevski Reverge Studios, Inc. http://www.revergestudios.com/reblog/index.php?n=ReCode