Michael Fawcett ha escrito:
On Feb 3, 2008 6:20 PM, "JOAQUIN LOPEZ MU?Z" <joaquin@tid.es> wrote:
----- Mensaje original ----- De: Alberto Ganesh Barbati <AlbertoBarbati@libero.it> Fecha: Domingo, Febrero 3, 2008 12:39 pm Asunto: Re: [boost] [flyweight] Review period extended to February 3 Para: boost@lists.boost.org
One such scenario is right there in the GoF book, the word- processing application that uses one flyweight object for each glyph in the document. I have another case in an project I am working on: in a 3D application, I have heavyweight 3D mesh objects that might be shared among several actors. The key of a 3D mesh is just its filename. I don't want to load an entire mesh into memory just to find out that I have it already. Yes, I could delay the actual loading of the mesh until the first time it is actually used, but that would be impractical for at least two reasons: 1) any error encountered while loading the mesh would occur in the wrong place and couldn't be handled properly, 2) the place where the mesh is used is inside a tight rendering loop with strict real-time requirements which can't be blocked by costly I/O operations.
OK, I'd classify these two examples as scenarios where K and T contain esentially the same info but the translation function f() is computationally expensive. This is a valid context, just not the one I deem the most common.
Just to chime in here, that is also my use case, and I add textures (images) to that mix. I usually have a flyweight factory that holds large 3D meshes, and another one that holds textures. Lookup is done based on name, and construction requires loading a file from disk.
FWIW, all of my flyweight implementations have been key based (the map/set problem you spoke of), but I often wished for a set-based implementation too. I think offering both would be the correct way forward.
Good to know there's a potential for the keyed variant. Would you support then the provision of regular flyweight and also keyed_flyweight as exposed in my prior post? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo