共享内存中向量的结构

Question

I have following struct:

struct outData{   
    int a;
    float lat, lon;
}

which is used for IPC via shared memory. Now i want to update it to look something like this:

    struct outData{
        int a;   
        std::vector<std::pair<std::string, int>> allInts;
        std::vector<std::pair<std::string, float>> allfloats;
}

my shared memory is 4096 Bytes big for convienience, so that i don't have to modify a sizeof(outData) line of code every time i make changes to the struct.

When i create such a struct with dynamic members is it guaranteed that they are all created after the (int a) and therefore in the shared memory?

what about vectors of vectors like?

    struct outData{
        int a;   
        std::vector<std::pair<std::string, int>> allInts;
        std::vector<std::pair<std::string, float>> allfloats;
        std::vector<std::pair<std::string, std::vector<byte>>> allByteMessages;
}

Wow thanks for the fast answers! Based on your input i worked out this solution:

struct outData{
    int *iarray;
    float *farray;
} gtempStruct; 

SetSharedMem(std::vector<std::pair<int, float>> &input)
{
    void * p_v;
    gtempStruct.iarray = new int[input.size()];
    gtempStruct.farray = new float[input.size()];
    fillStruct(input);
    outData *p_oD = (outData *) p_Shm; // p_Shm = pointer to shared memory start
    *p_oD = gtempStruct;
    p_v = p_oD;
    p_v = reinterpret_cast<char*>(p_v) + sizeof(outData) -1;
    p_v = reinterpret_cast<void*>(p_v);
    memcpy(p_v, gtempStruct.iarray, sizeof(int)*input.size())
    p_oD->iarray = (int*) p_v;
    .
    .
    .
}

This works, but it's not very thoroughly tested. Thank you!

Answer 1

This can't work. The strings won't be in shared memory. The std::string object will be, but its contents won't be. The same is true for std::vector<byte> . The vector object will be in shared memory, but its contents won't be.

Both of these classes have no idea how big their contents will be when they're constructed. So their static content just includes enough information to find their dynamic content. The dynamic content is allocated separately.

If you're going to use shared memory, you must define the contents of that shared memory at the byte level. Classes with internal absolute pointers will not work. If you need pointers, you'll have to make them relative to the start of the shared memory segment so that they're meaningful across processes.

Answer 2

I'm not sure what you mean by "is it guaranteed that they are all created after the (int a) and therefore in the shared memory".

However, I think that you can't use objects with virtual tables (any object with at least one virtual function) in shmem. This will probably cause a crash when any such function (the destructor, for instance) is called.

This is in addition to the fact that the memory used by the array is dynamically allocated, ie the actual array is located elsewhere.

You probably will need to resort to using a custom structure, something like:

struct {
    int arraySize;
    int array[];
}

Answer 3

This is just barely possible, but not worth it.

The std::string and std::vector classes store data outside of themselves, usually on the heap allocated with new. You can pass a different allocator as a template parameter, in which case that will be used instead of new. You could, in theory, write an allocator that understood your shared memory. Note that writing a reliable allocator is hard.

Also, the std structures have internal pointers. If the virtual address of the shared memory is different in the two processes (which is likely) then those pointers will go to strange parts of memory.

Note that you can put plain old c-style arrays in structs, and those will do what you want. Including, you can use a variable length struct, provided you don't do very c++ish things to it.

Answer 4

Probably won't work.

• As pointed out by @DavidSchwartz the vector will store the actual strings in internally managed memory (which of course doesn't have any respect to whatever proprietary shared memory mechanism you have).
• Any non-POD data type normally has a hefty amount of auto-generated code that will be stored at a location that you can't control: virtual table, auto-generated constructors etc. There are ways to control this behavior but it's not trivial, not always possible and not always good enough.