From: Ion GaztaÃ±aga (igaztanaga_at_[hidden])
Date: 2008-02-05 11:44:22
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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk