"vicente.botet" ha escrito:
Hi all,
I don't see any comment during the review respect to the "Alternative/simpler configuration interface" originated by Peter Dimov. http://svn.boost.org/svn/boost/sandbox/flyweight/libs/flyweight/doc/review_n...
Joaquin, you write in this section "An aim of Boost.Flyweight is to provide maximum customizability so as to meet everybody's needs from basic users to programmers with very specific requirements"
I think that the proposal of Peter is more open, because there are less constraints in the template parameter. But even in this case the user needs factories, and the policy problem will now be reported on the factory class.
Correct. More open here does not necessarily mean more powerful --we simply charge the user with more work to do. The question is whether the current policy decomposition is good enough so as to not need a blanket variation such as Peter's proposal.
The real problem is if the current interface reponds to the goal of the library. I'm not sure that the current policies are all orthogonal, and complete respect to the domain, I need more time to understand how all these policies interact between.
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.
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.
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!
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. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo