----- Original Message ----- Joaquín Mª López Muñoz wrote
"vicente.botet" ha escrito:
For example, can the current design manage with interprocess flyweights? I'm thinking about the possibility to have flyweights fields in a multi_index stored on shared memeory, for example.Which policies will we reused and which ones added? If this is possible and natural, do you think that this could be included in the list of future work?
This can be done by providing an interprocess-compatible holder, factory and locking policy. Tracking would not be affected. Instead of a custom factory, we can also have an interprocess-compatible associative container and use it with the assoc_container_factory adaptor.
I can try to put an example together in the examples section. However, I don't know if this is a common enough need to promote it to lib status.
The example will be enough for me to probe the extension mechanisms.
Maybe this should be managed orthogonally but, can the current design manage with persistent flyweights? Which policies will we reused and which ones added?
In this case, we'd need the factory itself be serializable. The rest of policies wouldn't be affected, AFAICS.
If this is possible and natural, do you think that this could be included in the list of future work?
I can also try to provide an example for this. Whether the scenario has some practical applicability, I don't really know, I'd love to hear from potential users on this one.
I don't know if there are potentials users, but the fact we can do it reinforce the credibility of the current design. So the example will be welcome.
Joaquin I understand your concern, if we need to change the core then we recover only some lines of code of the flyweight class. So we can ask ourselfs why not to define a new class?
Any way, let me purpose you an alternative witch do not suffer of "demands a slightly less terse syntax"
// default configuration typedef flyweight<T> fw_t1;
// change core implementation typedef flyweight<T, core<shared_ptr_core> > fw_t2;
// or even with the deduced parameters, change core implementation typedef flyweight<T, shared_ptr_core > fw_t2;
// change some aspect of the default core as now typedef flyweight<T, no_tracking > fw_t3;
This will complicate only the flyweight class which needs to take care of the exclusion of the parameters. And of course this will need a description of what is expected from a core.
This is an interesting approach, transferring the more cumbersome syntax to the core replacement case.Thanks for the suggestion!
You are welcome
I don't know if the Boost.Parameter library takes care of the exclusion aspect?
What do you think?
This could be done with Boost.Parameter, yes.
I will take a look. Thanks for all --------------------------- Vicente Juan Botet Escriba