$include_dir="/home/hyper-archives/boost/include"; include("$include_dir/msg-header.inc") ?>
Subject: Re: [boost] flyweight - gsoc idea - multikey-value flyweight
From: Vicente J. Botet Escriba (vicente.botet_at_[hidden])
Date: 2016-02-16 02:43:39
Le 15/02/2016 07:51, Joaquin M LópezMuñoz a écrit :
> Vicente J. Botet Escriba <vicente.botet <at> wanadoo.fr> writes:
>
>> Hi Joaquin,
>>
>> I have a use case where I have several keys to the same flyweight.
>>
>> I was trying to associate a multi-index as factory, but I don't see how
>> it could be done.
>>
>> I believe that I would need something like a multikey_value<Value,
>> KeyExtractor1, KeyExtractor2>
>>
>> where KeyK should be deduced from KeyExtractorK.
>>
>> Have you found this use case already?
>>
>> Do you think this could be a good GSoC project?
> Hi Vicente
>
> This is the first time I hear about such use case... intriguing.
> Can you elaborate a bit more?
>
> * Can you provide a motivating example?
Let say you are writing an application that manage with some entities. 
You have two kind of operator that use a specific protocol and each 
protocol identify these entities using a key MOi. Suppose that you 
application use a library that has an interface that use different keys 
to identify these same entities, because it is using an internal 
protocol. You want also to have some CLI for debugging purposes that 
uses strings to identify these same entities.
All these keys are isomorphic so you can move from one key to the other 
using a specific algorithm. However this transformation could be more 
expensive than required. So you decide to store all these isomorphic 
keys in a AllKeys class. This class can be constructed from any key and 
deduce the others.You create the corresponding associative containers 
that give access to AllKeys from any of those keys. The application can 
store a smart pointer to this AllKeys object to identify the entity and 
all the mappings to all the external keys.
IMO this is a particular case of multi-index where the stored object is 
const, and all the stored information can be deduced from any key.
This is what I would expect a multi-key flyweight provide.
> * What are the contidions in which flyweight(k1)==flyweight(k2),
> with type(k1)=K1, type(k2)=K2? Note that in the regular key-value case,
> identity of flyweights is defined as identity of keys.
The keys must be isomorphic.
> * How's this supposed to behave when K1=K2?
>
>
It is supposed to don't compile ;-). The user will need to use tagged 
types to make the difference.
In addition, in my application I have a not so big number of entities, 
so that I COULD create all the flyweight instances at compile time. 
Wondering if this particular case could have an implementation that 
performs better when the access is with done using constexpr keys.
Best,
Vicente