Re: [flyweight] Review period extended to February 3

Michael Fawcett ha escrito:

> On Feb 3, 2008 6:20 PM, "JOAQUIN LOPEZ MU?Z" <joaquin <at> tid.es> wrote:
> > ----- Mensaje original -----
> > De: Alberto Ganesh Barbati <AlbertoBarbati <at> libero.it>
> > Fecha: Domingo, Febrero 3, 2008 12:39 pm
> > Asunto: Re: [boost] [flyweight] Review period extended to February 3
> > Para: boost <at> 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

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost