Ion Gaztañaga ha escrito:
JoaquÃn M LópezMuñoz wrote:
Besides regular flyweight and keyed_flyweight, there's a third potential variant, namely tha in which the flyweight is keyed but the key is not stored separately and can be obtained from T. I'd like to ask you: in your particular use cases, do your mesh classes store (apart from their data) the name of the file the data was brought from, i.e. can you obtain K from T? I wonder whether this third variant is worth implementing after all, given ther difficulties STL containers have at comparing elements with external keys.
This approach has been implemented in Boost.Intrusive. The user gives a key and a comparison functor compatible with the container Predicate and compares that key with stored values types. Basically this approach was provided to be able to efficiently implemented map-like containers over intrusive sets. This approach can be also used to search for prefix keys in ordered containers so that one can efficiently get the first element that begins with a certain key prefix. The approach is certainly efficient and I like it, but it can be a bit dangerous for the general case.
In intrusive "insert_check" compares the key and checks for duplicates. "insert_commit" uses information from the previous function and inserts a real value type. The key used in "insert_check" does not need to be enough to create a value type, just enough to find one element. Flyweight certainly does not need this flexibility and I don't think it's the place for such a general low level mechanism. But keys that are convertible to value types (const char * vs. std::string) might be interesting use cases to try to implement that third potential variant in a safe way.
As I explained in my previous post to Alberto, the problem is that variants 1 (classical) and 2 (external key) can be implemented with dumb factories, while 3 seems to demand more intelligent components based on B.MI, B.Intrusive or sometihng like that. Wouldn't users be satisfied with variant 2 as a substitute? Joaquín M López Muñoz Telefónica, Investigación y Desarrollo