G'day. Ion Gaztañaga <igaztanaga <at> gmail.com> writes:
However, being from the old school, [...]
So why are you proposing a Boost library? :-) (I hope that emoticon was big enough!)
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.
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.
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.
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. 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. Cheers, Andrew Bromage