I have a VM/mmap abstracting library (https://github.com/psiha/vm) and recently I tried to leverage it in conjuction with Boost.Container to create persisting STL-like containers (at least ones with contiguous storage).
First I tried hacking up an 'extended allocator' (that provides the extend and shrink functionality, which maps great onto the VM 'mindset') - however this failed because Boost.Container has the assumption that an extended allocation remains at the same base address - which need not hold with VM (re)allocations - if you run out if address space the allocation can be expanded 'in-place' (i.e. without any copying) yet still change its (virtual) address (and this is perfectly safe for trivially moveable types) - would you consider changing your logic to support such scenarios (i.e. checking/calculating a possible base address offset first after a successful expand, bwd or fwd, operation)?
Secondly I tried rolling my own VM-based vector to then use it as a backing sequence for boost::container::flat_set. This initially failed because I (re)used checked/'safe' iterators in debug builds as provided by default by Microsoft's STL yet Boost.Container in various places tries to convert an end iterator into its underlying 'raw' pointer or reference which causes assertion failures at runtime with checked iterators (as it is not actually allowed). I was able to workaround this by using non-checked iterators when interoping with Boost.Container yet this is something that should be fixed.
(I understand this is actually a separate issue/bug so I'll file it also as such).
I have a VM/mmap abstracting library (https://github.com/psiha/vm) and recently I tried to leverage it in conjuction with Boost.Container to create persisting STL-like containers (at least ones with contiguous storage).
First I tried hacking up an 'extended allocator' (that provides the extend and shrink functionality, which maps great onto the VM 'mindset') - however this failed because Boost.Container has the assumption that an extended allocation remains at the same base address - which need not hold with VM (re)allocations - if you run out if address space the allocation can be expanded 'in-place' (i.e. without any copying) yet still change its (virtual) address (and this is perfectly safe for trivially moveable types) - would you consider changing your logic to support such scenarios (i.e. checking/calculating a possible base address offset first after a successful expand, bwd or fwd, operation)?
Secondly I tried rolling my own VM-based vector to then use it as a backing sequence for boost::container::flat_set. This initially failed because I (re)used checked/'safe' iterators in debug builds as provided by default by Microsoft's STL yet Boost.Container in various places tries to convert an end iterator into its underlying 'raw' pointer or reference which causes assertion failures at runtime with checked iterators (as it is not actually allowed). I was able to workaround this by using non-checked iterators when interoping with Boost.Container yet this is something that should be fixed. (I understand this is actually a separate issue/bug so I'll file it also as such).