Boost.Interprocess accessing an unordered_map in shared memory.

Hi, I am trying to create a unordered_map in shared memory using Boost Interprocess library. Here, is the code, which I'm trying to use (taking examples from Boost Interprocess documentation): #include <boost/interprocess/managed_shared_memory.hpp> #include <boost/interprocess/allocators/allocator.hpp> #include <functional> #include <boost/functional/hash.hpp> #include <boost/unordered_map.hpp> #include <iostream> #include <string> #include <boost/interprocess/containers/string.hpp> namespace bipc = boost::interprocess; typedef bipc::allocator<char, bipc::managed_shared_memory::segment_manager> CharAllocator; typedef bipc::basic_string<char, std::char_traits<char>, CharAllocator> ShmemString; struct Person { int age; ShmemString name; double salary; Person(int i, double sal, const char* s, const char_allocator& a) : age(i), name(s, a), salary(sal) { } void print() {} } typedef ShmemString KeyType; typedef Person MappedType; typedef std::pair< KeyType, MappedType > MapPersonType; typedef bipc::allocator< MapPersonType, bipc::managed_shared_memory::segment_manager > ShMemAllocator; typedef boost::unordered_map< KeyType, MappedType, boost::hash<KeyType>, std::equal_to<KeyType>, ShMemAllocator > PersonMap; In the main reader program, I create a map in the shared memory and I insert an object in this map: int main() { bipc::managed_shared_memory segment(bipc::create_only, "MySharedMemory", 65536); PersonMap *persons = segment.construct<PersonMap>("MyHashMap") ( 3, boost::hash<ShmemString>(), std::equal_to<ShmemString>() , segment.get_allocator<MapPersonType>()); char_allocator alloc(segment.get_allocator<char>()); Person p1(20, 10000, "ABC", alloc); persons->insert(MapPersonType(ShmemString("Person1", alloc), p1)); } However, when I am trying to access the map in the reader program, I need to use a syntax like persons->at(ShmemString("H", segment.get_allocator<char>())).print(); However, I would prefer to do this with a std::string, which results in compilation errors: persons->at(std::string("H")).print(); Is it possible to write the above statement, i.e. accessing the map allocated in shared memory with std::string? Thanks.

El 11/03/2013 13:20, lazylabs@gmail.com escribió:
However, I would prefer to do this with a std::string, which results in compilation errors:
persons->at(std::string("H")).print();
Is it possible to write the above statement, i.e. accessing the map allocated in shared memory with std::string?
No, as the key_type is not std::string. It's a bit ugly but to fix this has no easy fix. Best, Ion

On Tue, Mar 12, 2013 at 2:21 AM, Ion Gaztañaga <igaztanaga@gmail.com> wrote:
El 11/03/2013 13:20, lazylabs@gmail.com escribió:
However, I would prefer to do this with a std::string, which results in compilation errors:
persons->at(std::string("H")).print();
Is it possible to write the above statement, i.e. accessing the map allocated in shared memory with std::string?
No, as the key_type is not std::string. It's a bit ugly but to fix this has no easy fix.
Thanks. It's ugly for sure, but does it have any performance impact as well? As I understand, the reason why we cannot lookup ShmemString with std::string is because of the template argument, which I have given while creating the unordered_map: std::equal_to<KeyType>, Just guessing, if something can be done here?

On Tue, Mar 12, 2013 at 12:43 AM, <lazylabs@gmail.com> wrote:
On Tue, Mar 12, 2013 at 2:21 AM, Ion Gaztañaga <igaztanaga@gmail.com> wrote:
El 11/03/2013 13:20, lazylabs@gmail.com escribió:
However, I would prefer to do this with a std::string, which results in compilation errors:
persons->at(std::string("H")).print();
Is it possible to write the above statement, i.e. accessing the map allocated in shared memory with std::string?
No, as the key_type is not std::string. It's a bit ugly but to fix this has no easy fix.
As I understand, the reason why we cannot lookup ShmemString with std::string is because of the template argument, which I have given while creating the unordered_map:
std::equal_to<KeyType>,
Just guessing, if something can be done here?
It seems to me that within the last year or so another person on this mailing list (who had his own local idiosyncratic string type) was asking about passing std::string or const char* key arguments for map lookup. I don't even think it was specific to Interprocess. I believe he was proposing string comparators accepting range-of-characters rather than a specific string type. Sorry for vagueness; I don't have time to search for it myself...

On Tue, Mar 12, 2013 at 6:49 PM, Nat Linden <nat@lindenlab.com> wrote:
On Tue, Mar 12, 2013 at 12:43 AM, <lazylabs@gmail.com> wrote:
On Tue, Mar 12, 2013 at 2:21 AM, Ion Gaztañaga <igaztanaga@gmail.com> wrote:
El 11/03/2013 13:20, lazylabs@gmail.com escribió:
However, I would prefer to do this with a std::string, which results in compilation errors:
persons->at(std::string("H")).print();
Is it possible to write the above statement, i.e. accessing the map allocated in shared memory with std::string?
No, as the key_type is not std::string. It's a bit ugly but to fix this has no easy fix.
As I understand, the reason why we cannot lookup ShmemString with std::string is because of the template argument, which I have given while creating the unordered_map:
std::equal_to<KeyType>,
Just guessing, if something can be done here?
It seems to me that within the last year or so another person on this mailing list (who had his own local idiosyncratic string type) was asking about passing std::string or const char* key arguments for map lookup. I don't even think it was specific to Interprocess. I believe he was proposing string comparators accepting range-of-characters rather than a specific string type.
Sorry for vagueness; I don't have time to search for it myself...
Sorry if I was vague, I was more interested in "why" this cannot be done. I already got a No (and that too from the library implementer himself. Thanks) and based on that I have already implemented a different solution in my code, to have integer lookups, rather than string-based lookups. Thanks.
participants (3)
-
Ion Gaztañaga
-
lazylabs@gmail.com
-
Nat Linden