C ++ interface destructor

[Go to] a post to illustrate this issue

Problem:
The following sectionCodeWill there be problems after execution?
Base class:
Class cbase
{
Public:
Virtual void virtualfun1 (cstring strfun1) = 0;
};

Subclass:
Class cderived: Public cbase
{
Public:
Cderived ();
Virtual ~ Cderived ();
Virtual void virtualfun1 (cstring strfun1 );
PRIVATE:
Cstring m_strfun1;
};
Cderived: cderived ()
{
}
Cderived ::~ Cderived ()
{
}
Void cderived: virtualfun1 (cstring strfun1)
{
M_strfun1 = strfun1;
}

Customer Code:
Cbase * pbase = new cderived ();
Pbase-> virtualfun1 ("test ");
Delete pbase;

answer/analysis:
yes!
Memory leakage (my test platform: vc6) occurs as long as it is run.
debugger output information:
dumping objects->
strcore. CPP (118): {76} normal block at 0x003a36e8, 16 bytes long.
data: 01 00 00 00 03 00 00 00 00 00 00 00 74 73 72 00
Object dump complete.
Note:
01 00 00 00 00 00 00 00 00 00 00 00 00 74 73 72 00
This part of data may be the memory protection data of the debugger, not verified
the problem surface is m_strfun1. The problem is actually that cbase does not provide virtual destructor, and the above problem is solved by adding a virtual destructor to cbase;
cause When deleting pbase, it only calls the cbase destructor (non-virtual, the compiler completes it in the back, and has not verified pure virtual classes ), as a result, the cderived destructor is not called, and m_strfun1 is not released.
afterwards, I checked the materials and explained them in detail in Article 14 of Objective C ++. If you are interested, please refer to them.
if you analyze this code, it can be effectively solved. If you put this code in a large Program , when similar memory leaks occur, it may be difficult to trace them, so we need to lay a good foundation and write every line of code.

conclusion:
1. c ++ has poor basic skills, lacks understanding of destructor, and lacks understanding of internal behaviors of compilers.
2. ignoring code changes, especially the code generated by the wizard, a virtual destructor is automatically created through the Wizard.
3. the key to finding the problem is more difficult than solving the problem. Because this memory leak occurs in a large program and involves other DLL files, it takes a long time to locate it, determine the leaked code line.
4. debugging is a comprehensive test of basic knowledge. It best reflects the technical depth of a person. After in-depth analysis, it can deepen the understanding and memory of technical details.