From: Michael Fawcett (michael.fawcett_at_[hidden])
Date: 2008-02-04 16:15:34
On Feb 4, 2008 3:44 PM, Joaquín M LópezMuñoz <joaquin_at_[hidden]> wrote:
> Michael Fawcett <michael.fawcett <at> gmail.com> writes:
> > On Feb 4, 2008 12:16 PM, Joaquín Mª López Muñoz <joaquin <at> tid.es> wrote:
> > >
> > > 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?
> > I support the notion of being able to lookup existing instances by
> > key. However you implement it, I hope it will have an elegant syntax,
> > and an extremely efficient implementation. Remember that this pattern
> > is used often in games and 3D graphics, where extra copies are not an
> > option, regardless of how pretty it makes the code look.
> Besides regular flyweight and keyed_flyweight, there's a third
> potential variant, namely tha in which the flyweight is
> keyed but the key is not stored separately and can be obtained
> from T. I'd like to ask you: in your particular use cases, do
> your mesh classes store (apart from their data) the name of
> the file the data was brought from, i.e. can you obtain
> K from T?
Almost never, and neither do the textures usually. The textures in
particular are very lightweight - they only store a GLuint (OpenGL
typedef for unsigned int). They also have a custom deleter that
deletes the texture from video memory by calling glDeleteTextures().