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