In boost::interprocess
documentation it is said as requirement for containers to be stored in shared memory:
- STL containers may not assume that memory allocated with an allocator can be deallocated with other allocators of the same type. All allocators objects must compare equal only if memory allocated with one object can be deallocated with the other one, and this can only tested with
operator==()
at run-time. - Containers' internal pointers should be of the type
allocator::pointer
and containers may not assumeallocator::pointer
is a raw pointer. - All objects must be constructed-destroyed via
allocator::construct
andallocator::destroy
functions.
I am using gcc 4.7.1 with -std=c++11 (and boost 1.53). Is it safe to use the below defined ShmVector
type?
typedef boost::interprocess::allocator<int,
boost::interprocess::managed_shared_memory::segment_manager> ShmemAllocator;
typedef std::vector<int, ShmemAllocator> ShmVector;
I tried a dummy process which uses this type, and it looks it is working, but I am still not sure that the vector in gcc4.7.1 does satisfy all the requirements. I am especially not sure about the first requirement.
#include <iostream>
#include <boost/interprocess/allocators/allocator.hpp>
#include <boost/interprocess/managed_shared_memory.hpp>
#include <vector>
#include <cstdlib> //std::system
typedef boost::interprocess::allocator<int,
boost::interprocess::managed_shared_memory::segment_manager> ShmemAllocator;
typedef std::vector<int, ShmemAllocator> ShmVector;
int main(int argc, char *argv[])
{
if(argc == 1){ //Parent process
struct shm_remove
{
shm_remove() { boost::interprocess::shared_memory_object::remove("MySharedMemory"); }
~shm_remove(){ boost::interprocess::shared_memory_object::remove("MySharedMemory"); }
} remover;
//Create a new segment with given name and size
boost::interprocess::managed_shared_memory segment(boost::interprocess::create_only,
"MySharedMemory", 65536);
//Initialize shared memory STL-compatible allocator
const ShmemAllocator allocator(segment.get_segment_manager());
ShmVector* v = segment.construct<ShmVector>("ShmVector")(allocator);
v->push_back(1); v->push_back(2); v->push_back(3);
//Launch child process
std::string s(argv[0]); s += " child ";
if(0 != std::system(s.c_str()))
return 1;
} else { // Child process
//Open the managed segment
boost::interprocess::managed_shared_memory segment(
boost::interprocess::open_only, "MySharedMemory");
//Find the vector using the c-string name
ShmVector *v = segment.find<ShmVector>("ShmVector").first;
for (const auto& i : *v) {
std::cout << i << " ";
}
std::cout << std::endl;
}
}
In C++ 11 allocator rules have slightly changed, but I don't think it affects your question.
You probably want to know first what standard says about it. But you'd actually want to check whether your specific STL implementation conforms to the standard and doesn't contain bugs.
For the second part I'd strongly recommend going to sources of and just checking that, it's not that hard actually.
Also, you could write your tests to see if it's actually working properly:
- Create custom allocator:
- use some custom type as pointer, const pointer;
- In
construct()
,destruct()
count number of calls;
- Create
YourCustomType
to be used with the allocator which also counts number of constructions/destructions. - Now, create
std::vetor<YourCustomType, YourCustomAllocator<YourCustomType>>
instance, insert some elements, clear the vector, destroy it and see if:- number of
construct()
destruct()
calls is equal to number of constructions destructions ofYourCustomType
. typeid(YourCustomAllocator::pointer) == typeid(std::vetor<YourCustomType, YourCustomAllocator<YourCustomType>>::pointer)
- number of
That's how you can be sure that all restrictions apply.
As for the first part of the question, here's an old C++ standard (not C++ 11).
1 There's no way (properly implemented) vector will take an allocator out of nowhere. It'll use whatever allocator you provide, and will use it for everything. As for operator==, it is implemented in boost's allocator and thus it's boost's problem to make operator== work as they require. Although I wasn't able to find confirmation in the standard.
2 Unless there's a bug, std::vector<T, YourAllocator>::pointer
should be allocator's pointer. cppreference.com says that, and the standard says that, (look for "Template class vector"):
typedef typename Allocator::pointer pointer;
typedef typename Allocator::const_pointer const_pointer;
Although the same standard says this about allocators: Implementations of containers described in this International Standard are permitted to assume that their Allocator template parameter meets the following two additional requirements beyond those in Table 6.
--All instances of a given allocator type are required to be inter- changeable and always compare equal to each other.
--The typedef members pointer, const_pointer, size_type, and differ- ence_type are required to be T*, T const*, size_t, and ptrdiff_t, respectively.
So, actually standard doesn't allow using any pointer types, but my guess is that actual STL implementations will work.
3 Just check the std::vector<T>::clear()
method implementation to see if allocator::destroy is called. Check std::vector<T>::resize()
method's implementation to see if allocator::construct is used. I was not able to find requirement of calling destroy and construct in the standard.
I think the answer is no. Because in practice (in C++98) and in theory (C++11 standard), std::vector
pointer cannot be something else than T*
.
That is why boost::interprocess::vector<T>
uses boost::container::vector<T, boost::interprocess::allocator<T>>
(instead of std::vector<T, boost::interprocess::allocator<T>>
).
I have no reputation to comment, so I have to answer.. If two allocators compare equal, they are interchangeable. Allocators of same type that compare unequal may, for example, be initialized with different (shared) memory. See Allocator:
a1 == a2 => returns true only if the storage allocated by the allocator a1 can be deallocated through a2. Establishes reflexive, symmetric, and transitive relationship. Does not throw exceptions.
So, if your ShmVector
instances are created with ShmemAllocator
s which compare equal, you must be safe.
来源:https://stackoverflow.com/questions/15298007/does-stdvector-satisfy-the-container-requirements-for-boost-interprocess-alloc