I think this is their intended purpose, but I don't like using them that way. It gets confusing and brevity isn't attained as you have to qualify things. Namespaces support a "let's just agree to disagree" approach that isn't a resolution, but is the best that can be done at times. Do you think this shmem functionality should be integrated with the std containers?
Some STL implementations are close to achieve Shmem compatibility and it's not difficult to achieve if they use allocator::pointer typedefs in their implementation instead of raw pointers.
Does shmem support multi_index_containers?
No.
Or, depending on how shmem fits into the picture, should B.MI take the lead in supporting shmem functionality internally? Y'all have more flexibility in the B.MI case as it isn't part of the standard.
To be able to support Multi-index in shared memory we would need to rewrite it to replace all raw pointers with allocator::pointer typedefs. I haven't looked through multiindex code but this can be a big task. There is nothing that shmem can do to support multiindex if it uses raw pointers. But I think that multiindex and shmem can be a good base for in-memory data-bases. Regards, Ion