Re: [boost] [flyweight] Review period extended to February 3

From: Joaquín Mª López Muñoz (joaquin_at_[hidden])
Date: 2008-02-05 12:49:19

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