Memory leak or no?

I started to run a job & then after a several 100K interations & a few hours into the primary loop I realized that forgot to do some basic cleaning at the bottom of the loop (blame it on the cold meds :D). Thing is, the program hasn't died on me yet & I would have thought it should.

Question: Does g++ handle the following, or is my proggie doomed?

here's a sanitized snippet:

Code:

---

    while (q0.FetchRow()){
        int n;

        sprintf(sql, "SELECT stuff FROM table WHERE Id = %s", q0.Row[0]);
        Query q1(sql); //Object creation

        n = 0;
        while (q1.FetchRow())
            if (someFunc(atoi(q1.Row[0]))) ++n;
        if (n >= number)
            cout << "some results "  << q0.Row[2]  << endl;
        //delete q1; <--THIS IS THE LINE I FORGOT!
    }

---

g++ isn't smart enuf to call the destructor when I reuse the "Query q1" object is it?

Quote:

---

Originally posted by rafe
I started to run a job & then after a several 100K interations & a few hours into the primary loop I realized that forgot to do some basic cleaning at the bottom of the loop (blame it on the cold meds :D). Thing is, the program hasn't died on me yet & I would have thought it should.

Question: Does g++ handle the following, or is my proggie doomed?

here's a sanitized snippet:

Code:

---

    while (q0.FetchRow()){
        int n;

        sprintf(sql, "SELECT stuff FROM table WHERE Id = %s", q0.Row[0]);
        Query q1(sql); //Object creation

        n = 0;
        while (q1.FetchRow())
            if (someFunc(atoi(q1.Row[0]))) ++n;
        if (n >= number)
            cout << "some results "  << q0.Row[2]  << endl;
        //delete q1; <--THIS IS THE LINE I FORGOT!
    }

---

g++ isn't smart enuf to call the destructor when I reuse the "Query q1" object is it?

---

When you declare the instance of the object like..

Query q1(sql);

You are declaring it on the stack. This memory will be automatically released when the object goes out of scope. I wouldn't instantiate it in a loop though. Anyways you don't need "delete" because you don't dynamically allocate it with "new". So it was automatically cleaned up when it left scope.

> I wouldn't instantiate it in a loop though.

newbie's confused sorry. I haven't really left the scope of the outer loop where I declared the object. This thing is still happily instantiating in the loop like mad.

So I have on the stack my class definition OK. However the object does have some pointers to dynamic data associated with it. what happens to the dynamic data from previous instances? Still there?

Quote:

---

Originally posted by rafe
> I wouldn't instantiate it in a loop though.

newbie's confused sorry. I haven't really left the scope of the outer loop where I declared the object. This thing is still happily instantiating in the loop like mad.

So I have on the stack my class definition OK. However the object does have some pointers to dynamic data associated with it. what happens to the dynamic data from previous instances? Still there?

---

To understand what happens take a look at this trivial example:

Code:

---

#include <iostream>
using namespace std;

class CClass
{
  private:
    int m_x, m_y;

  public:

    CClass( ) : m_x( 0 ), m_y( 0 ) { cout << "Constructor!" << endl; }
    ~CClass( ) { cout << "Destructor!" << endl; }
};

int main( void )
{
  int i;

  for( i = 0; i < 2; ++i )
  {
    CClass oops;
  }

  return 0;
}

---

You can see the output is like this:
Constructor!
Destructor!
Constructor!
Destructor!
Press any key to continue

So in your constructor your saying you dynamically allocate memory for use with your object? Well that answer is simple. Just make sure you delete the memory in the class destructor. You can see it gets called at the end of the loop.

Let me know if more questions.

Crystal clear, THANK YOU!

Constructor & destructor handle the dynamic data, yes.

Silly me, I went to a pointer to object to allow me to explicitly create/delete in the loop. Totally unnecessary as per your previous post.

No more questions on this thread.