Boost logo

Boost :

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


Joaquin M Lopez Munoz wrote:
> Scott McMurray <me22.ca+boost <at> gmail.com> writes:
>
>> On Wed, Nov 12, 2008 at 16:09, Joaquin M Lopez Munoz <joaquin <at> tid.es>
>> wrote:
>>> 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?
>>>
>> Perhaps there is no constructor for a texture that takes the
>> key, but instead there's some load_texture function that can
>> construct a texture from the key?
>
> Then you can do something like this:
>
> struct texture
> {
> ...
> };
>
> texture load_from_texture(const std::string)
> {
> ...
> }
>
> struct loaded_texture:texture
> {
> loaded_texture(const std::string& str):
> texture(load_from_texture(str))
> {}
> };
>
> typedef flyweight<key_value<std::string,loaded_texture> >
> texture_flyweight;
>
> Note that loaded_texture can be treated as an implementation
> artifact: texture_flyweight is convertible to texture, which
> is the type you're interested about.
>

But loaded_texture's can't share any state or be initialized with state
other than the key.

class TextureFactory
{
public:
    TextureFactory( Log& log ) : m_log( log ) {}

    GLuint LoadImage( const std::string& filename )
    {
       if( ExtensionMatches(filename,".png") )
       {
          m_log << "Loading png: " << filename;
          return m_pngLoader.Load( filename );
       }
       else
       {
          throw UnsupportedImageFormat( filename );
       }
    }

    // rest of factory implementation goes here

private:
   Log& m_log;
   PngLoader m_pngLoader; // heavy object to construct
};

-- 
Michael Marcin

Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk