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

12 Nov 2008


      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