Re: [boost] [flyweight] key value with objects not constructible from a key

Subject: Re: [boost] [flyweight] key value with objects not constructible from a key
From: Michael Marcin (mike.marcin_at_[hidden])
Date: 2008-11-12 16:53:31

Joaquin M Lopez Munoz wrote:
> Michael Marcin <mike.marcin <at> gmail.com> writes:
> 
>> joaquin <at> tid.es wrote:
>>> Michael Marcin escribió:
> [...]
>> Let's say my key is a filename and my value is a texture.
>>
>> If texture has to be constructible from key then texture has to have 
>> direct access to file and image loading functionality. I can't pass any 
>> information other than the key to the construction site without 
>> resorting to singletons.
> 
> OK, please help me make out a more complete picture of
> the use case you've got in mind. Imagine you have a flyweight
> type that behaves the way you need/want, let's call it
> texture_flyweight. The associated key is std::string and the
> associated value is texture. Now, you write the following:
> 
>   texture_flyweight fw("wood.texture");
> 
> If an equivalent flyweight already exists then there is no
> problem, fw will be assigned the same texture object, this is
> how Boost.Flyweight currently works. Now, imagine that
> no equivalent texture exists, and yet you can't construct
> a texture object from "wood.texture" alone. How would you
> have then the above statement behave?
> 

It would go to the factory's construct method which might look like:

void TextureFactory::construct( void* address, const std::string& filename )
{
    // complex work involving lots of 3rd party libraries
    // happens here
    GLuint glTextureName = LoadImage( filename );

    // texture stays simple
    new(address) Texture( glTextureName, filename );
}

-- 
Michael Marcin