When I first thought about it, the approach that I considered was to use two classes. mmaped_file represents a file which has zero or more mmaped regions, and mmaped_region which represents a single region. the Off top of my head, something like this might be appropriate:
I see. Another possibility is a "mmapped_file" class that produces "file_mappings". However this has not the lifetime security your approach has, since your mapped_file won't be destroyed until the last mapped_region is destroyed. However, being from the old school, I don't like much the mandatory use of shared_ptr in the interface (so that mapped_file must be allocated only via new). Anyway, I get the idea of two separate concepts and I can see that your approach saves a lot of lifetime issues, and I don't think file_mappings will be objects that will be created and destroyed very heavily. file_mappings could have also ordering operators so that we can store them in containers. I think both your mapping approach and boost::shmem::mmapped_file can be complementary, being boost::shmem::mmapped_file for simple uses and this multi-mapping approach for advanced ones. If you want to implement it, I'm ready to help or if you just want to help, I'm ready to implement it for a future Shmem version. Thanks, Ion