[probing interest]AssocVector (and other parts of Loki)
>From my experience, the main parts of Loki that people are missing in Boost are: a) Singleton b) policy-based smart_ptr c) AssocVector d) Factories e) (rarely)Visitor Nobody uses multimethods apparently. Since there are people working on a, b, d and e, I would like to ask the following questions: 0) Are you interested in adding AssocVector to Boost? (there seems to be at least _some_ interest[1]) 1) Is there interest in additional interfaces(set, multiset, multimap) described in [1] or is std::map-like container enough? 2) What other parts of Loki you would like to see in Boost? [1]http://article.gmane.org/gmane.comp.lib.boost.devel/116873
"Mikhail Glushenkov" wrote:
From my experience, the main parts of Loki that people are missing in Boost are: a) Singleton b) policy-based smart_ptr c) AssocVector d) Factories e) (rarely)Visitor Nobody uses multimethods apparently.
Some of them are being worked on or ready to review (a, b, c, maybe e, d is unfinished). Good multimethods can be found on http://www.codeproject.com/cpp/mmcppfcs.asp.
Since there are people working on a, b, d and e, I would like to ask the following questions: 0) Are you interested in adding AssocVector to Boost? (there seems to be at least _some_ interest[1])
Yes. You can find current implementation in shmem library in Files section /Pavel
Pavel Vozenilek <pavel_vozenilek <at> hotmail.com> writes:
Yes. You can find current implementation in shmem library in Files section Well, there is actually another(probably better) implementation in yahoo groups files section, which includes also set-like container. Unfortunately, it was abandoned for some reason. The version that Shmem uses was copied from Loki nearly verbatim. What I want is to finish that first implementation (though I intend to make it simpler), so I need to know what people want from container like this besides what Loki's AssocVector has to offer.
"Mikhail Glushenkov" wrote:
Yes. You can find current implementation in shmem library in Files section Well, there is actually another(probably better) implementation in yahoo groups files section, which includes also set-like container. Unfortunately, it was abandoned for some reason.
Probably lack of time.
The version that Shmem uses was copied from Loki nearly verbatim. What I want is to finish that first implementation (though I intend to make it simpler), so I need to know what people want from container like this besides what Loki's AssocVector has to offer.
One feature may be to have policy { KeepKeysAndValuesTogether, KeepKeysSeparate } so the lookup could be faster (the key table would better fit the cache. Another is to have equivalent of "Boost.SmartContainers" functionality. Support for Serialization. Another is more optimized bulk insert than in Loki. /Pavel
Compatibiliy with MultiIndex library would be also helpful, to use this maps as multiindex internal maps, but I don't know if this is more an issue of MultiIndex mantainer. Although I've mentioned it in a previous mail, I would request the independence from the memory model via allocator interface. I could help checking preliminary versions to check them with shared memory allocators. Regards,. /Ion Another feature is ----- Original Message ----- From: "Mikhail Glushenkov" <bbman@mail.ru> To: <boost@lists.boost.org> Sent: Wednesday, February 02, 2005 9:15 PM Subject: [boost] Re: [probing interest]AssocVector (and other parts of Loki)
Pavel Vozenilek <pavel_vozenilek <at> hotmail.com> writes:
One feature may be to have policy [...] Another is more optimized bulk insert than in Loki.
Thanks!
Ion Gaztañaga <ion_g_m <at> terra.es> writes:
Compatibiliy with MultiIndex library would be also helpful, to use this maps as multiindex internal maps, but I don't know if this is more an issue of MultiIndex mantainer.
Hola Ion, Main problem with having something like an assocvector index in Boost.MultiIndex is that indices are required to be node-based, while much of the power of an assocvector comes from its use of contiguous memory to achieve excellent performance. So I doubt the merge would be satisfactory. That said, I prompted some days ago about interest on a random-access index for the library. If I finally write this, it could be used as an implementation basis for an associative random-access index. On another topic, "compatibility with MultiIndex" amounts to rewriting the stuff: it is very difficult that common code can be shared between a container and its index counterpart. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo PS: I took a glance at your sharedmem lib and it looks dandy!
Hola Joaquin,
Main problem with having something like an assocvector index in Boost.MultiIndex is that indices are required to be node-based,
I didn't know that, thank you for pointing it out.
PS: I took a glance at your sharedmem lib and it looks dandy!
Thank you. In the future I plan to take a look to multiindex to see if a multiindex can be placed as a memory manager database so that one could erase an object using the address or the name. I also would want to see if I can place a Multiindex object in shared memory, because it could be a great in memory database. I hope I can look at these issues in a few months. Regards, gracias por el comentario, /Ion
Pavel Vozenilek wrote:
"Mikhail Glushenkov" wrote:
From my experience, the main parts of Loki that people are missing in Boost are: a) Singleton b) policy-based smart_ptr c) AssocVector d) Factories e) (rarely)Visitor Nobody uses multimethods apparently.
Some of them are being worked on or ready to review (a, b, c, maybe e, d is unfinished). Good multimethods can be found on http://www.codeproject.com/cpp/mmcppfcs.asp.
Since there are people working on a, b, d and e, I would like to ask the following questions: 0) Are you interested in adding AssocVector to Boost? (there seems to be at least _some_ interest[1])
Yes. You can find current implementation in shmem library in Files section
Pavel and I have been talking, and agree that the multiton would be best implemented in terms of an assoc_vector. Are there still plans to work on this? -Jason
participants (5)
-
Ion Gaztañaga -
Jason Hise -
Joaquin M Lopez Munoz -
Mikhail Glushenkov -
Pavel Vozenilek