Thread: vector / linkedlists of pointers, freeing memory

  1. #1
    Registered User
    Join Date
    Oct 2003
    Posts
    29

    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.

  2. #2
    Devil's Advocate SlyMaelstrom's Avatar
    Join Date
    May 2004
    Location
    Out of scope
    Posts
    4,079
    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.
    Last edited by SlyMaelstrom; 10-04-2006 at 03:14 AM.
    Sent from my iPadŽ

  3. #3
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Ireland
    Posts
    8,446
    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...
    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  4. #4
    Devil's Advocate SlyMaelstrom's Avatar
    Join Date
    May 2004
    Location
    Out of scope
    Posts
    4,079
    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.
    Sent from my iPadŽ

  5. #5
    Registered User
    Join Date
    May 2006
    Posts
    630
    You might consider using smart pointers.

  6. #6
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Ireland
    Posts
    8,446
    > 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 brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  7. #7
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,895
    Quote 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.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Mutex and Shared Memory Segment Questions.
    By MadDog in forum Linux Programming
    Replies: 14
    Last Post: 06-20-2010, 04:04 AM
  2. Problems with shared memory shmdt() shmctl()
    By Jcarroll in forum C Programming
    Replies: 1
    Last Post: 03-17-2009, 10:48 PM
  3. New to c++/c and dont understand the use of memory pointers
    By (Slith++) in forum C++ Programming
    Replies: 6
    Last Post: 12-19-2005, 05:30 PM
  4. pointers and memory
    By itld in forum C++ Programming
    Replies: 4
    Last Post: 02-06-2002, 11:34 PM
  5. Allcoating memory and not freeing it
    By lambs4 in forum C Programming
    Replies: 1
    Last Post: 09-05-2001, 11:32 AM