3

I'm working on an application that is composed of 2 processes that have to share some data structures. These classes are organized in different libraries and the libraries are used in different applications.

  • My first attempt was to use Named Shared Memory in Win32 but the problem here is that I can't use STL containers.
  • Looking for a solution, I've found Boost Interprocess and, if I understand, I have to change all the STL containers, in my classes, to "STL" Boost Interprocess containers.

So, is there any other method to share classes or structures using STL (in Windows)? The goal is to not create too much dependence from Boost in our libraries.

Thanks

Community
  • 1
  • 1
sibanez
  • 33
  • 4
  • 1
    You would need to create a custom allocator for the container. See [this site](http://bitsquid.blogspot.se/2010/09/custom-memory-allocation-in-c.html) for some explanation about it. – Some programmer dude Sep 18 '12 at 13:17

3 Answers3

7

The reason that Boost.Interprocess has its own container classes is that most current implementations do not fully support the standard in regard of allocators.

The Boost.Interprocess container classes are fully-compliant implementations of the standard containers, so you can use them as drop-in replacements for the standard containers and switch to your vendor-supplied containers when they are fixed to support the standard allocator protocol.

I'm not sure whether I can explain it any better than the documentation, but the biggest problem is that shared memory is mapped into different processes at different virtual addresses, so any pointers used within the container must be a relative pointer (e.g. from the beginning of the segment). The standard allocator model supports this, but the container must also support this by using Allocator::pointer instead of T *. When all implementations are fixed to support this, the Boost.Interprocess containers will no longer be necessary.

Alternatively, you may be able to map the memory at the same virtual address in each process; if you do this then you can use your existing implementation's containers, since raw pointers will work correctly.

ecatmur
  • 152,476
  • 27
  • 293
  • 366
1

Personally, I would avoid the shared structure approach. An alternative would be to give ownership of the structure to one of the two processes. The other process would access it by sending messages to the first process.

If you're absolutely set on using shared memory, then you can certainly use it with STL. First, you will have to create a custom allocator for your containers. The allocator will allocate memory from the shared memory block. Also, since the STL containers are not thread safe, you will have to write a synchronized wrapper for the containers using a named mutex.

Peter Ruderman
  • 12,241
  • 1
  • 36
  • 58
1

The real issue with using standards compliant STL collections with boost::interprocess is that the standard explicitly allows collections to assume that allocators of the same type are equivalent, that allocators don't need any stored state, and that the pointer type can be ignored and T* can be used instead.

The boost::interprocess documentation explains this better than I can, but my summary is:

  • The C++ standard allows stateless or stateful allocators
  • The C++ standard allows using T* for pointers even if the allocator specifies another type
  • boost::interprocess REQUIRES stateful allocator support (so the owning memory segment can be used in all allocations)
  • for most uses, boost::interprocess uses alternative pointer types - for non-trivial applications this will be offset_ptr
  • boost::interprocess collections - map/vector/etc - (these are currently typedefs of boost::container types) provide all of these optional implementation details that boost::interprocess requires

So, even if your current STL collections support the requirements of boost::interprocess, and they probably don't, there is NO guarantee provided by the C++ standard that they will continue to provide these requirements in the future. The only sensible approach for collections used in a boost::interprocess application is to use the boost collections that guarantee compliance with boost:interprocess requirements - either from boost::container or boost:interprocess:collections

rudy
  • 11
  • 1