Re: [flyweight] Review period extended to February 3

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.

Regards,

Ion
_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost