Is there any memory leak in the code snippet?

[forumuser11@gmail.com]

#include <iostream>
using namespace std;

class A
{
  int x;
   
public:
   A(int x1) {x=x1;}
   virtual void fun() {cout<<"A";} 
   ~ A(){  }; 
};

class B: public A
{
  int y;
   
public:
   B(int x1,int y1):A(x1) {y=y1;}
   virtual void fun( ) {cout<<"B \n";} 
   ~ B(){  }; 
};

int main()
{

   A* a1=new B(1,2);  // Is there any memory leak as destructor is not declared as virtual ? 
   a1->fun();                // Object of B is created on heap 

   B b2(3,4);                // Is there any memory leak as destructor is not declared as virtual ?
   A* a2= &b2;            // Object of B is created on stack
   a2->fun(); 

  delete a1;   //Deleting obejct created on heap but it wont call destructor of class B as it's not vritual.
}

[nuzzle]

---

[monarch_dodra]

You have a potential memory leak, and a potential for a future memory leak:

   A* a1=new B(1,2);  // Is there any memory leak as destructor is not declared as virtual ? 
   a1->fun();                // Object of B is created on heap

If fun throws an exception, then you've just leaked. Right now, the chances that fun does throw are slim to none, but not inexistant. Furthermore, somebody could change func in the future in such a way that an exception be thrown, and you'd be none the wiser.

   A* a1=new B(1,2);  // Is there any memory leak as destructor is not declared as virtual ? 
   a1->fun();                // Object of B is created on heap 

   bool monarch_bug_fix = is_valid(a1);
   if (monarch_bug_fix == false)
   {
      return; //a1 is not valid in this context, we exit
              //Oops, forgot to clean up.
   }

   B b2(3,4);                // Is there any memory leak as destructor is not declared as virtual ?
   A* a2= &b2;            // Object of B is created on stack
   a2->fun();


  delete a1;   //Deleting obejct created on heap but it wont call destructor of class B as it's not vritual.

I magine somebody in the future makes a change to your code and inserts a premature return. leak.

Anytime you don't use managed resource, you have a huge potential for leaks.

To answer your question though, the rule is pretty easy. An object that is newed must be destroyed by the corresponding delete. For a stack based object, that is always the case. For newed object, you can either make the destructor virtual (so you are guaranteed to call the right destructor polymorphically), or you can pray you call the correct destructor (ie, call delete on the right type)

[superbonzo]

actually, deleting a pointer to a base class which points to a derived object whose base has a non virtual destructor gives undefined behavior. Therefore, the line "delete a1;" gives undefined behavior ( which includes the possibility of a memory leak; indeed, if I remember well, that line will leak memory or corrupt the heap in VC++ 2008 ).

[forumuser11@gmail.com]

I agree with this point. Even if the derived class do not contain dynamic memory allocation, destructor in base class MUST be declared virtual to avoid any undefined behaviour.
Do you agree?

#include <iostream>
using namespace std;

class A
{
  int x;
   
public:
   A(int x1) {x=x1;}
   virtual void fun() {cout<<"A";} 
   virtual ~ A(){  }; //Destructor must be declared virtual...
};

class B: public A
{
  int y;
   
public:
   B(int x1,int y1):A(x1) {y=y1;}
   virtual void fun( ) {cout<<"B \n";} 
   ~ B(){  }; 
};

int main()
{
   B b2(3,4);                // Is there any memory leak as destructor is not declared as virtual ?
   A* a2= &b2;            // Object of B is created on stack
   a2->fun(); 
}

[Lindley]

If you intended to delete through a base class pointer, yes.

(Note that it is never valid to delete[] an array of derived objects through a base class pointer.)

[nuzzle]

I agree with this point. Even if the derived class do not contain dynamic memory allocation, destructor in base class MUST be declared virtual to avoid any undefined behaviour.
Do you agree?

I agree.

I wasn't aware that the C++ standard defines the behaviour as undefined in this case. But since it does the destructor must be declare virtual as you say. Otherwise all bets are off.

[laserlight]

I agree with this point. Even if the derived class do not contain dynamic memory allocation, destructor in base class MUST be declared virtual to avoid any undefined behaviour.
Do you agree?

I disagree. It is a should, not a must, since undefined behaviour might not actually occur even if the base class destructor is not virtual.

[monarch_dodra]

The point is this:

Base p = new Derived;
delete p;

The line delete p will call Base::~Base. If it is virtual, than it will actual resolve to Derived::~Derived, and everything will be safe. If it isn't, then you'll call the base destructor on the derived object -> Boom.

That said:

Derived p = new Derived;
delete p;

Here this code is perfectly fine regardless of virtuality of the destructor.

As already mentioned: If your object will be destroyed via a base pointer, than yes, the destructor must be virtual.

The perfect example of this is private inheritance. If you inherit privately from a base class, you know no one will handle your class via it's base, so you have no need for a virtual destructor.

[forumuser11@gmail.com]

Laserlight,

It's like in rainy season one should carry umbrella though there is no gurantee of rain...Similarly, as language std says deleing object of derived class through base class pointer is UNDEFINED behaviour...We should respect that and carry umbrella in rainy seasons though it may not rain....We never know when undefined behaviour happens...

Other members,
any comments?

[nuzzle]

I disagree. It is a should, not a must, since undefined behaviour might not actually occur even if the base class destructor is not virtual.

That's a misconception.

Just because you didn't notice anything in particular when the undefined behaviour moment passed, it sure did "occur".

[laserlight]

It's like in rainy season one should carry umbrella though there is no gurantee of rain...Similarly, as language std says deleing object of derived class through base class pointer is UNDEFINED behaviour...We should respect that and carry umbrella in rainy seasons though it may not rain....We never know when undefined behaviour happens...

Exactly.

(As noted earlier, we're talking about public inheritance here though. For private inheritance it is not a concern.)

[monarch_dodra]

Well I'll make one last comment. In your original code, there is no memory leak, there is undefined behaviour. Different things...

[forumuser11@gmail.com]

thanks everyone

[laserlight]

That's a misconception.

Just because you didn't notice anything in particular when the undefined behaviour moment passed, it sure did "occur".

No. Refer to monarch_dodra's post #8, though you need to tweak the code snippets to make p a pointer in both cases.