遍历qvector,嵌套QVector指针内存处理

I’ve inherited a substantial Qt5 project, where the accumulative memory leakage is becoming a serious issue. (Yes, memory leakage should rarely be tolerated but with real life budget and time constraints…).

This GUI reads image data into objects of a voxel class, to be displayed graphically. The data comes either from file or buffer (if acquired live) and is stored as a nest qvector, ie:

QVector < QVector > cVoxel;

When an image is read from file, cVoxel is initialized using QVector.resize(0).

cVoxel.resize(0);

When an image save to file is opened, a local Voxel pointer is created and pushed to the end of cVoxel, once for every pixel so looping over all rows and columns:

for (iRow = 0; iRow < nRows; ++iRow)

{

for (iCol = 0; iCol < nCols; ++iCol)

{

Voxel *v = new Voxel;

cVoxel[iRow].push_back(v);

// Code for reading data into cVoxel removed here

…

}

}

Courtesy of the useful comments below, I’ve now had some success in seeing memory usage decrease in the Windows Task Manager, by nesting destruction of the cVoxel QVector in my CTOR. Along the lines of:

for (iRow = 0; iRow < nRows; iRow++)

{

for (iCol = 0; iCol < nCols; iCol++)

{

delete cVoxel[iRow][iCol];

}

}

Ideally, a major rewrite is the best solution. But in the real world, I’ll have to try and fix the bigger leaks and hope that’s enough until there’s enough resources available for a more ideal solution.

I’ve looked at memory leakages in Voxel itself, but there’s nothing obvious there.

My research reveals that looking at the Windows Task Manager for memory consumption isn’t entirely reliable (Win7 isn’t a Real-Time OS..), but if opening a file increases the application memory consumption from 16M to 81.5M, then surely there should be some memory decrease if the allocated memory in cVoxel is successfully released? If I keep opening and shut images, the app’s memory consumption keeps increasing in similar step. It never decreases after closing any/all opened images.

Right now, there’s no attempt to release any memory assigned (using the new operator) to cVoxel. I have tried a few approaches (and read to learn more), but so far litte luck.

QVector is excellent at taking care of it’s own memory handling, but I’m stuck with this nest QVector setup, and simply relying on QVector’s squeeze(), resize(), or similar will only leak memory (which is already the case for other variables in the project.. I have run the project through Visual Leak Detector, so I’ve an idea which are the serious culprits, and which ones are small fish)

—-EDIT —-

Apologies for the messy ad-hod commenting below, but this is certainly helping me reduce the memory leakages (complete stoppage will hopefully happen in due course..).

I’ve edited in-line above to (hopefully) make this post clearer, and removed my best case effort as it had no impact on the memory leak. The significant alteration above are the (2) brief paragraphs in italics.

I also need to investigate @richardcitter (sp?) polymorphism related suggestion.

— EDIT3 —

Removed Edit2, posted that (new) question separately here.

Also, I’m pretty confident the answer below should fix this question – I just need to figure out how to use qvector.resize() or find a workaround to it.

解决方案

@SomeProgrammerDude: You got me 9/10 towards the solution. I don’t know whether I should edit your answer or use this, so moderator(s) please edit accordingly.

As outlined in a connected SO post, I decided against smart pointers in the end. The above solution introduced (for me) the issue of the compiler trying to reference a deleted function. Otherwise it is correct with a couple of modifications:

QVector < QVector > cVoxel;

Initialisation:

cVoxel.resize(0);

Memory assignment:

{

for (int i = 0; i < rows; ++i)

{

cVoxel.push_back( QVector () );

for (int j = 0 ; j < cols ; ++j)

{

Voxel *v = new Voxel;

cVoxel[i].push_back(v);

}

}

}

Finally DTOR releasing the memory:

int iRow, iCol;

for (iRow = 0; iRow < rows; iRow++)

{

for (iCol = 0; iCol < cols; iCol++)

{

delete cVoxel[iRow][iCol];

}

}