Re: [Boost-users] [shmem] New bugfix version in Boost Vault and sandbox cvs
Ion Gaztañaga wrote:
Jan Stetka(e)k dio:
Yes I understand that I can't use shmem::map and std::map if they are
both on the global namespace. I've looked at the implementation of the std::map header from the STL implementation that is included in vc++ 7.2 and that doesn't forward declare std::list in <map>. This is a design
issue rather than a bug. Why forward declare shmem::list by including it in map.hpp when it isn't used?
All classes in Shmem include shmem_fwd.hpp or container_fwd.hpp where Shmem defines default arguments (for example default Less, or Allocator template parameter). That's why you get the predeclaration of list including map. Another alternative would be to declare a *_fwd.hpp for each class defined in Shmem, but you would get a lot of extra headers, and I would have a lot of work to maintain.
Even if I don't include list predeclaration with map, I'm free to use any Shmem container in any Shmem class (for example, I can implement a pooled allocator using a list container), so it's likely that a Shmem class include will include more Shmem classes (predeclarations, or full declarations). I don't consider it a design error, but a design choice. What I see dangerous is pushing two namespaces, std, and shmem to the same context because they have similar classes. An alternative would be to rename shmem classes like "vector" to "shmem_vector", .... But weren't namespaces born to allow that?
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? In the meantime, I think shmem_vector is better. Does shmem support multi_index_containers? 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. Brian www.webEbenezer.net
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
Ion Gaztañaga wrote:
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.
Have you submitted a proposal to the library working group? Jeff
Jeff Flinn(e)k dio:
Ion Gazta�aga wrote:
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.
Have you submitted a proposal to the library working group?
No, but it a good idea. Ion
I certainly wasn't getting at renaming the shmem containers. Although I
am not the developer of this library I think there are more important
issues such as the ambiguous native function calls. With this code:
#include "boost/shmem/containers/map.hpp"
#include
participants (4)
-
bwood -
Ion Gaztañaga -
Jan Stetka -
Jeff Flinn