why virtual destructor being private called

Question

4.60/5 (5 votes)

See more:

Hi

I was just doing simple things in destructor but i found something which is not clear to me.

here the code below

C++

#include "stdafx.h"
#include "conio.h"
class cFather
{
	public:
	virtual ~cFather()
	{
		printf("\n~cFather()");	//dont ask me why i used printf instead cout	
	}
};

class cSon : public cFather
{
	~cSon()
	{
		printf("\n ~cSon()");		
	}
};


int _tmain(int argc, _TCHAR* argv[])
{
	class cFather * pObjFthr = new cSon();
	delete pObjFthr;
	getch();
	return 0;
}

output
~cSon()
~cFather();

Question:
As you can see the destructor in cSonClass is private but being called.
I just wnt to know the mechanishm what is running under the hood.

Thank in advance.

Posted 20-Aug-12 21:04pm

kaushik4study

Updated 20-Aug-12 21:20pm

Mohibur Rashid

v2

Add a Solution

Comments

stib_markc 21-Aug-12 3:22am

If you understand inheritance and control flow during object creation and object destruction then first solution(by SA) will answer your question.

kaushik4study 21-Aug-12 3:32am

@stib_markc i am bit confused in the solution given by -SA. I understand when we use delete on heap the appropriate destructor will be called but i guess(i know i am wrong but dont know where) the destructor should be public. same as if you remove the virtual keyword from cFather clas the it will throw an error which should be the same case for cSon class. please tell me i am really missing something.
Thanks

stib_markc 21-Aug-12 4:51am

First you have to understand what does the word 'virtual' means. And irrespective of the access specifier(public or private)/modifier(virtual or not), a destructor will be called when you call "delete"(for objects created on heap) or when the stack variables go out of scope. Please read polymorphism and inheritance and how they are used on constructor and destructor.

3 solutions

Solution 2

// I just wnt to know the mechanishm what is running under the hood.

All derived destructors will be virtual (automatically)
since it is so at the base,

in this case - any protection has no role :)

Posted 20-Aug-12 23:27pm

Eugen Podsypalnikov

Comments

kaushik4study 21-Aug-12 8:14am

are you sure because inheritance with virtual function do not follow this concept. they do care what is the scope of the fucntion.
I am not arguing but could not get the right answer.

Eugen Podsypalnikov 21-Aug-12 9:00am

Sure :) , that is why you can see the "~cSon()" output. Try it without the keyword virtual in the base, and you will win a memory leak :)

Add a Solution

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

CPallini · Accepted Answer · 2012-08-21T10:01:00

Actually destructor has no special role in that, try, for instance

C++

#include <iostream>

class A
{
public:
  virtual void show()=0;
};

class B: public A
{
private:
  virtual void show(){ std::cout << "hi" << std::endl;}
};

int main()
{
  A *p = new B();
  p->show();
}

The point you spotted comes from polymorphism (or, better, as SAK noted, from late binding) and as strange as it looks, it is the correct behaviour, see , for instance Public virtual function derived private in C++[^] at Stack Overflow.

Sergey Alexandrovich Kryukov · Accepted Answer · 2012-08-20T21:10:00

Solution 1

Destructors are called automatically when an instance is deleted (in case when heap is used) or goes out of some block (in case of a local variable). They don't have to be accessible from outside of the class/structure.

[EDIT #1]

On OP's request, I'm adding some links:
http://www.learncpp.com/cpp-tutorial/86-destructors/[^],
http://www.learncpp.com/cpp-tutorial/69-dynamic-memory-allocation-with-new-and-delete/[^].

I would advise you to read through all of the manual before you process — it can be very useful. I could be some other manual or a book though. This one is especially good to have:
http://www.amazon.com/The-Programming-Language-Special-Edition/dp/0201700735/ref=sr_1_1?ie=UTF8&qid=1345580932&sr=8-1&keywords=Stroustrup+C%2B%2B[^],
http://www.amazon.com/C-Programming-Language-4th-Edition/dp/0321563840/ref=sr_1_3?ie=UTF8&qid=1345580932&sr=8-3&keywords=Stroustrup+C%2B%2B[^],
http://www.amazon.com/Primer-Plus-Edition-Developers-Library/dp/0321776402/ref=sr_1_8?ie=UTF8&qid=1345580932&sr=8-8&keywords=Stroustrup+C%2B%2B[^].

[EDIT #2]

Another useful manual:
http://www.cplusplus.com[^].

And links on the topics being discussed:
http://www.cplusplus.com/doc/tutorial/classes/[^],
http://www.cplusplus.com/doc/tutorial/dynamic/[^].

—SA

Posted 20-Aug-12 21:10pm

Sergey Alexandrovich Kryukov

Updated 21-Aug-12 10:55am

v3

Comments

nv3 21-Aug-12 3:23am

5 ed. What probably surprised kaushik4study is the failing symmetry. To instantiate an object one must well have access to the constructor. Well observed, kaushik4study!

Sergey Alexandrovich Kryukov 21-Aug-12 3:26am

As there is a "fool's infinity" know from philosophy, there could be some "fool's symmetry". There is no such thing in the OOP; that said, it's just because it's not totally foolish... :-)
Thank you very much,
--SA

CPallini 21-Aug-12 3:34am

That's not the whole picture. There is polymorphism here too. The compiler (at least GCC) does not allow the direct contruction of cSon, that is
cSon * ps = new cSon();

Sergey Alexandrovich Kryukov 21-Aug-12 13:20pm

You should have said "late binding". The term "polymorphism" is only used in consideration of a set of object in case of more than one objects with possibility of having more than one run-time type. Besides, cSon is directly constructed because it's the case when the default constructor is provided, right?
--SA

CPallini 21-Aug-12 15:39pm

'Late binding' is the technique that allows polymorphism (at least ) in C++.
With 'direct construction' I meant: "without cFather class you couldn't have an instance of cSon".

Sergey Alexandrovich Kryukov 21-Aug-12 16:41pm

Yes, of course, but you are not saying the two terms are equivalent, right? And how these two terms are different? The way I explained above. With you first statement I think it's clear, you don't really object, it looks like.

Now, how about second one, "without cFather"?
I don't think you are going to say that this is impossible:


cSon * son = new cSon(); // all correct, in fact

So, what one cannot do without cFather? :-)
--SA

CPallini 22-Aug-12 5:43am

Did you try to compile it?

Sergey Alexandrovich Kryukov 22-Aug-12 11:27am

You are confusing me... I will try... :-)
--SA

Sergey Alexandrovich Kryukov 22-Aug-12 13:18pm

Uf-ff... OP's code compiles. And creation also compiles, of course. It's delete which does not compile because of the private destructor.


	cFather * pFather = new cSon();
	delete pFather;
	cSon * pSon = new cSon(); // did you mean this is invalid by "The compiler (at least GCC) does not allow the direct contruction of cSon"
        //compiles and perfectly valid so far

But this does not compile:


	delete pSon; // cannot access private destructor

So, may be you mean something correct, but you mislead me by your statement that construction will not pass. Is it possible that you actually meant distraction?

Anyway, construction cSon * pSon = new cSon(); was something I've written. OP did not do event that, so he would not have this problem.

--SA

CPallini 22-Aug-12 14:14pm

No, I don't mean distrAction... :-)

Yes, of course it is the private destructor the problem. However it would:
(1) prevent object construction on the stack.
(2) give you a memory leak if the object is created on the heap.

Sergey Alexandrovich Kryukov 22-Aug-12 14:33pm

Sure. But now, isn't it you turn to compile?
Are you saying that even construction could fail to compile in GCC? Could you please try it with the the first fragment of my code above (and exact same class declarations as OP;s) and tell me if GCC compilation fails? Please... I would be strange.
--SA

CPallini 22-Aug-12 16:32pm

I already did it. In fact
cSon * ps = new cSon();
compiles fine (contrary to what I claimed). However such statement will inevitably cause a memory leak.
On the other hand, the stack-allocated equivalent
cSon c;
is rejected by the compiler.

Sergey Alexandrovich Kryukov 22-Aug-12 18:17pm

That's the different story, could be considered explainable. Your point on the leak is valid.
Now, that's was the useful discussion,
Thank you,
--SA

CPallini 23-Aug-12 6:23am

BTW my 5.

Sergey Alexandrovich Kryukov 23-Aug-12 10:39am

Oh, thank you very much; now I'm not sure I deserved it this time...
--SA

CPallini 23-Aug-12 11:35am

In any case you didn't deserve that ugly one.

kaushik4study 21-Aug-12 8:17am

@Cpallini but it does.i tried it and its working. suggest me the reason for this.

Sergey Alexandrovich Kryukov 21-Aug-12 13:22pm

Indeed, new cSon is valid. What CPallini says ould be the case if you explicitly declared a constructor. But this is the case when a default parameterless constructor is provided.
--SA

kaushik4study 21-Aug-12 8:25am

@SA just in above example create object of cSon its obvious it will call the destructor when it will go out of the scope say out of main() so compiler generate compiler error for that. Infact if you make ~Cfather fucntion private then again compiler will generate the error. So class destructor being called (indirectly) out of the class. Please tell me how its working . basically calling of private destructor ?

Sergey Alexandrovich Kryukov 21-Aug-12 13:25pm

Now exactly. It would be so in the case if you declare a local variable:

{
    cSon mySon;
    //...
} //destructor is called

But! -- you use heap through "new cSon()", so you will need to delete it to reclaim heap memory; and it will call your destructor as well.
Is it clear now?

--SA

kaushik4study 21-Aug-12 15:08pm

@SA thanx for youf answer and it seems too logical can you please give the proper link for understanding detailed concept of it. (dont ask me to do google it because i could not find related document)
one more thing in the above example which you mentioned. if we use "new cSon " we need to reclaim heap i agree with that point but for that destructor should be public too.i am talking about single cSon class juts no inheritance now but private destructor. kill me if i am bothering you alot.:)...but really thax and appreciate ur comments

Sergey Alexandrovich Kryukov 21-Aug-12 16:32pm

Sure. Please see my updated answer, after [EDIT].
Please consider accepting this answer formally (green button) -- thanks.
If something needs clarification, your follow-up questions are of course very welcome.
--SA

why virtual destructor being private called

3 solutions

Solution 3

Solution 1

Solution 2

Add your solution here

Preview 0

why virtual destructor being private called

3 solutions

Solution 3

Solution 1

Solution 2

Add your solution here

Preview 0

Existing Members

...or Join us