Hi Andrew,
However, being from the old school, [...]
So why are you proposing a Boost library? :-)
Good point! Maybe because I felt old-school resources (IPC, shared memory, etc...) are not present in Boost ;-)
I don't like much the mandatory use of shared_ptr in the interface (so that mapped_file must be allocated only via new).
That's not true! You can take a shared_ptr to a static or auto object by using a custom deleter. This approach doesn't provide any safety in this case (since mmaped_region doesn't manage the lifetime of mmaped_file), but it works at least.
Right.
file_mappings could have also ordering operators so that we can store them in containers.
Yes. The application that I had in mind was an application-controlled buffer cache, so the ability to store them in containers is certainly a useful feature there.
The buffer cache is definitely a good tool to design. Don't forget two present it to a Boost review!
Yes. In fact, the more I think about it, the more I suspect that this is the better approach, with mmaped_file perhaps being a convenience wrapper built on top of the other two classes.
Yes, that would be easy.
In addition, while designing these classes, it may turn out that a more general memory mapped file library is warranted.
So in summary: We (I include myself) should work on supporting this functionality, but it's not a barrier to accepting Shmem into Boost.
Thanks. I think that multi-mapping functionality has many possibilities, so is definitely a good project. Cheers, Ion