The flyweight factory concept seems to be missing a key part of the GoF Flyweight pattern's FlyweightFactory participant. The GoF factory supplies the flyweight if one exists. This is what the current boost flyweight Factory concept does. If no flyweight exists the GoF flyweight factory creates one. In the boost flyweight library this functionality is somewhere else that doesn't seem to be described in the documentation. The name factory for what is currently in place is misleading. Isn't it really just an associative container? I'm trying to use flyweight to represent texture objects right now. These are surely a good candidate for use with flyweight as they are one of the examples given. My textures are fairly simple objects, with low coupling. Creating a texture is however expensive and has a lot of dependencies (libjpeg,libpng,etc). I typically have a TextureFactory which decouples the construction of a texture from the actual texture object and allows the work required to setup the various libraries to read images to be reused by all textures constructed from the same TextureFactory instance. It doesn't seem possible to have this decoupling with flyweight. Am I missing something? -- Michael Marcin