vector / linkedlists of pointers, freeing memory

In this code I noticed that the memory stays used when i press ctrl alt delete:

Code:

#include <vector>
#include <iostream>

using namespace std;

class someClass
{
public:
    someClass(double ix, double iy);
    ~someClass();
private:
    double x, y;
};

someClass::someClass(double ix, double iy)
{
    x = ix;
    y = iy;
}

someClass::~someClass() {}


int function()
{
    vector<someClass*> someClassList;
    
    double x = 0;
    double y = 0;
    
    int count;
    
    while (count < 500000)
    {
        someClassList.push_back(new someClass(x, y));
        x = x + .01;
        y = y + .01;
        count++;
    }
    
    /* USE someClassList here */
    
    // Delete it here but how?

    return 0;
    
}

int main()
{
    
    cin.get();
    for (int i = 0; i < 100; i++)
        function();
        
    cin.get();
    return 0;
}

I know I must delete the someClass pointers in the list but how? From using the search function of this board and finding a simular problem with a solution I have found and modified "int function()" to this:

Code:

int function()
{
    vector<someClass*> someClassList;
    
    double x = 0;
    double y = 0;
    
    int count;
    
    while (count < 500000)
    {
        someClassList.push_back(new someClass(x, y));
        x = x + .01;
        y = y + .01;
        count++;
    }
    
    /* New part */
    
    vector<someClass*>::iterator I = someClassList.begin();
    
    while (I != someClassList.end())
    {
        delete *I;
        I++;
    }
  
    return 0;  
}

Is this the corrent way to free the memory? Thank you for your time.

Sure, that looks fine, you don't necessarily have to use an iterator, though, you can access each element with the subscript operator or the at() method. An iterator works fine, though.

Code:

for(int i = 0; i < someClassList.size(); i++)
    delete someClassList[i];  // or someClassList.at(i) if you prefer

That should work, as well... maybe slightly slower or faster... I'm not sure.

EDIT: On testing the time it took to run the function with each deletion method of 500000 objects, it seems the iterator took on average 406 ticks, the subscript operator took an average of 422 ticks, and the at() operator took an average of 437 ticks where a tick represents 1/1000th of a second. Go figure.

Why strange? They are not that different results between the three tests. Also, the STL promise, I seem to remember, is that iterators be at least as fast (if not faster) than other access methods. Plus all three methods involve function calls.

i++ instead of ++i may also be penalizing one method more than another...

No, there was no difference between i++ and ++i. Likely, I imagine, because of compiler optimization. Regardless... I didn't find it very strange that the iterator was the fastest... I found it strange that at() was that much slower than the subscript operator. I would have suspected that both the operator and the at method would use the same pointer arithmetic to get the correct element, however it seems that my implementation of at() may in fact just return the subscripted item. Even still... just preserving the stack frames took longer than I expected it would.

You might consider using smart pointers.

> I found it strange that at() was that much slower than the subscript operator.

Well, at() does ensure bounds checking... not sure how this affects performance on situation where there is no throw, though. There is however (I think) at least one extra function call considering at() is called first and only then is somewhere inside the subscript operator overload called.

On my STLport implementation, at() and [] are nearly identical. at() is only marginally slower. Considering this library is highly optmized for speed (or so they say), maybe that's to be expected.

Originally Posted by Mario F.

Well, at() does ensure bounds checking... not sure how this affects performance on situation where there is no throw, though. There is however (I think) at least one extra function call considering at() is called first and only then is somewhere inside the subscript operator overload called.

Nah, it's all inlined. at() simply contains a single if testing the index to be greater than or equal to 0, and less than the vector's size. That accounts for the minimal difference.


The test is pretty much irrelevant anyway. The major part of the time is always used by the heap manager.