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