I agree. The problem is that Boost Thread seems to be in stand-by mode, so I don't know if we will have any chance to change the situation.
I think this is an important issue for Boost in general!
Are there any of the latter? A table would be quite useful here. For compilers with a reasonable hope of getting changes fed into the Standard Library implementation (e.g. gcc) it might be worthwhile to contact the maintainers about these limitations to see if they can be removed.
I have already commented this with Howard Hinnant and Paolo Carlini from libstdc++ in a private mail. They want to support shared memory allocators but the work is not trivial, since raw pointers are everywhere. I'm ready to help them.
OK, so users need to live with the shmem containers for a while. Thats OK. I think you should state this clearly at some point: "No Standard Library implementation currently available supports Shmem this way" or words to that effect. I just wanted to say that if you have "static const int a = 5" (like
enum { a = 5 };) declarations that are just constant integral values, there is no harm. Each process will read their own copy and since both will be the same (supposing they use the same version of the class, of course) there is no problem.
Perhaps the last clause of tha sentence should be re-written, or stricken entirely as it seems not to say much. Sorry about containers. They are not documented at all, since all are
standard C++ containers in boost::shmem namespace. The only new container family is the Loki AssocVector derived flat_map family. I agree that I should document that at least. I don't know if documentation for others is needed since they are standard C++ containers in boost::shmem namespace. But if this is what boosters want, I will document them (but it's quite a hard work).
It makes no sense to reproduce Standardese for the classes that simply mimic Standard Library containers, but I would certainly be interested to see some documentation for the flat_* containers and related classes. I will try to write a small paper about multi-segment shared memory
architecture (I mean allocating new segments when we need more memory) and the problems I've found when trying to construct them. But this will be after Shmem review ends (and if it's accepted, after I make the requested changes).
I look forward to it. Plane boarding. Skiing trip is finally here! -- Caleb Epstein caleb dot epstein at gmail dot