Allen Cronce wrote:
I was very excited about using the interprocess library to solve a set of problems in our current project, until I saw this post. We have to support 32 and 64 bit binaries. Falling back to using the low level utilities like mapped_region means that much of the appealing functionality from the interprocess library is unavailable to us.
Yes, you loose a lot of funcionality, but
I understand that certain functionally between different sized address spaces doesn't make sense. A very large shared space from a 64 bit process would not be addressable in 32 bits. But I doubt that people are really using this library to share address spaces larger than 4 gig. More than likely developers want to share comparatively small amounts of data between processes.
Is there any plan to add support for 32/64 bit in the future?
It's not that I don't find it interesting, especially the goal of having (if the ABI of two compilers is the same) portable managed segments (all internal poitners might be offset_ptr_32 or uint32_t, etc...). That would allow also quite portable (supposing alignment is correctly configured in the compilers) mapped files. But this requires a huge effort (I would need to rewrite all the allocation algorithms, containers, allocators, etc...) and I don't have time to implement this type of costly features. Best, Ion