From: Ion Gaztañaga (igaztanaga_at_[hidden])
Date: 2006-05-06 15:51:14
> 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