Michael Marcin escribió:
Joaquin M Lopez Munoz wrote:
The following might be one possible approach to your envisioned scenario using the technique proposed by Scott. There is one significant difference with the way TextureFactory is defined, namely that construct is required to return a Texture (your version does the construction using placement new).
I only chose the placement new because flyweight already has an allocator template parameter. If allocation became part of the factory then I think more cool option occur like polymorphic flyweights where a key constructs a derived type via the factory but the flyweight and calling code only knows about the base type.
I don't see how the use of allocators hint at the possibility to have polymorphic flyweights. flyweight<T> treats T as values --they are stored in a factory typically implemented with an associative container, and STL containers are not polymorphic. In order to have polymorphism you'd have to use something like flyweight<T*>.
Is this more similar to what you have in mind
That is certainly a lot closer.
I'm glad about it. This kind of techniques to bring external value factories into play were discussed in conversations with Alberto Barbati: http://lists.boost.org/Archives/boost/2008/09/142227.php where it was also pointed out that a future extension of key-value flyweights might accept additional "factory functors" to make this type of constructs explicit and thus avoid such admittedly contrived tricks. I don't plan to have this in the initial version of the library so as to be able to gain more real-life feedback, I hope in the meantime the techniques just described serve your purposes. Regarding the terminology issue with what "factory" really means within B.F, I think it'll help to clarify things to distinguish these two entities: * A *flyweight* factory is the entity in charge of producing flyweight objects on demand. This is what's called a factory in B.F. * A *value* factory is the entity that produces values from keys and other conextual information, like your TextureFactory. This concept is not currently explicit in B.f, though it can be more or less acommodated as shown previously and might receive official treatment in future releases of the lib via "factory functors".
I didn't know that flyweights could have multiple construction parameters. I didn't see any examples of that in the docs, it seems like a pretty cool feature you might show off somewhere.
It is documented in the reference and mentioned at a comment in one of the snippets of the tutorial: // flyweight<T> can be constructed in the same way as T objects can, // even with multiple argument constructors I might try to give it more prominence in the tutorial, though. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo