C ++数组“矩阵”交换（内存泄漏）

Question

I'm creating a block based engine and I was working on infinite loading. I was testing some code, but soon I noticed some troubles. At first I was using an std::unordered_map , storing xz as key and ChunkContainer* as value. I store this as pointers (with new) because it's such a big object it can't be all stored on the stack. It's size is: CHUNK_SIZE(32)^3 * WORLD_HEIGHT(8 amount of chunks in height) * 4(block bytes) = 1048576 bytes . (And that * 225 makes up my world.)

Then I swapped to using a big array instead of the std::unordered_map so I could achieve faster read speed. So I needed to swap the loading code. I came up with this code,

but I'm having some issues with a memory leak created when using this code:

for(int z = 0; z < size; z++){
    temp = loadedChunkContainers[(size-1)*size + z]; //Store the last container in a temp var

    for(int x = size-1; x > 0; x--){
        loadedChunkContainers[x * size + z] = loadedChunkContainers[(x-1) * size + z]; //Move all containers 1 to the right
    }
    int cx = temp.getX() - size;
    int cz = temp.getZ();

    temp.move(cx, cz);//Move the container internally
    loadedChunkContainers[z] = temp; //put the container back into the array, but this time on the first row
    buildQueue.push_back(&loadedChunkContainers[z]);
}

temp is a global variable because I can't store it locally because it will overflow the stack. I also can't use swap as it will also overflow the stack.

Should I even use this code? It works, but It's quite a slow way in the first place. Would there be another way to have the fastest read access while still being able to swap values (without memory leaks)?

Answer 1

An std::unordered_map will never store its elements "on the stack", so this is not a good reason to store pointers. You can basically forget all of your stack-related worries, here. With that goes away all your pointer troubles. Just store the elements directly and be done with it!

If you have measured the std::unordered_map version of your code and found that the (very fast) hash lookup is prohibitively slow in your application, by all means stick with your sparse array, but make it a std::vector so that elements are dynamically allocated [for you]. Then everything I said in the first paragraph still applies. :)