Hi Vicente, ________________________________________ De: boost-bounces@lists.boost.org [boost-bounces@lists.boost.org] En nombre de vicente.botet [vicente.botet@wanadoo.fr] Enviado el: martes, 09 de septiembre de 2008 7:48 Para: boost@lists.boost.org Asunto: Re: [boost] [flyweight] post-review version available
----- Original Message ----- From: "JOAQUIN M. LOPEZ MUÑOZ" <joaquin@tid.es> To: <boost@lists.boost.org> Sent: Monday, September 01, 2008 6:26 PM Subject: [boost] [flyweight] post-review version available
Hello,
I'm happy to announce the availability of the post-review version of Boost.Flyweight: [...]
Hi Joaquin,
I have take a look to the library.
The way you have integrated the Key-value in the flywight class is very elegant.
Thank you!
I have just some questions related to the integration of flywight<T> in multi_index. Can we use flywight<T> as a member field of a multi_index container?
Certainly. For instance: typedef flyweight<std::string> fw_string; struct element { fw_string x; fw_string y; element(const char* x,const char* y):x(x),y(y){} }; typedef multi_index_container< element, indexed_by< ordered_unique< member<element,fw_string,&element::x> >, ordered_non_unique< member<element,fw_string,&element::y> > >
multi_t;
int main() { multi_t m; m.insert(element("hello","boost")); m.insert(element("bye","world")); assert(m.find(fw_string("hello"))->y=="boost"); }
what about when the multi_index container is in shared memory?
For this to work you'd have to have flyweight<> itself placeable in shared memory, which currently is not the case :( This would be a tough exercise, as shared-memory compatibility affects all the components of flyweight: factory, tracking, holder, locking.
Thanks for the clear performance section you have added. You say "Actually the types tested are not exactly those listed above, but instrumented versions that keep track of the allocated memory for profiling purposes. "
These instrumented versions can be also useful to the user to make its own messures, are them available somewhere?
Yes, at the performance program source code, see http://tinyurl.com/66df5k .
Do you plan to manage the following items on the release 1.38 * On platforms on which static variables are unique inter DLL the intermodule_holder specifier type can be a static_holder_class.
Yes, this is something I still have in my todo list and plan to address in the following weeks. The problem is that I don't know where to ask about such platforms: I usually work with Windows where this situation does not happen; Are you acquainted with some environment where static vars don't get duplicated across DLLs? If so please contact me offlist and we can work something out.
* Add an exclusive core specifier (see my review) Otherwise, could you add them to the Future Work section?
This is not currently in my todo list. I'd prefer to wait and see how the current Boost.Flyweight version fares in the real world before deciding on the convenience of adding the core stuff. Having such capability from the start could be overdesigning things and exposes a lot of internal detail, which is something I always try to do with care.
I've runned the test and the examples on - g++ (GCC) 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)
Every think works well except the serialization test and example are broken. How do you plan to manage this issue as Robert do not plan to take in account the helper you need?
Well, I'm afraid B.F most likely will ship in 1.38 without serialization support. My plan is to begin working on adding helper support to Boost.Serialization and eventually gather evidence of its usefulness as a core Archive concept. When/if this happens I'll add serialization capabilities to B.F, but I doubt this'll develop before 1.38. Thank you very much for your post-review review. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo