Michael Marcin <mike.marcin <at> gmail.com> writes:
Joaquin M Lopez Munoz wrote:
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.
[...] OK, then we're back to my original question: how do yo expect the following statement to behave texture_flyweight fw("wood.texture"); when no previous equivalent flyweight object exists? Please note that I'm not fooling around your problem, I understand it but we have the crucial point that *all* the information necessary to construct the value should be available at the point of flyweight construction. This is not AFAICS a particular limitation of Boost.Flyweight, but just the way things are. This is why I'm inviting you to come up with a suitable creation process (regardless of whether it is implementable with B.F or not) so that I can see how you expect the value construction information to be provided. Just sketch how your ideal flyweight library should behave under these circumstances and we'll see whether B.F is up to the task or not. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo