My first close contact with run-time check #0

When a program is written one day, the following error prompt suddenly appears during debugging:

Run-Time check failure #0-the value of ESP was not properly saved stored ss a function call. this is usually a result of calling a function declared with one calling convention with a function pointer declared with a different calling convention.

I rarely encounter similar C ++ runtime check errors, not to mention Stack pointer loss, because the code I write is based on C ++'s default function call conventions, there should be no inconsistency between the function declaration and the call conventions defined by the function pointer.

The problem always needs to be solved. This error occurs every time the icomm object function is called. Check the status of the object and find that the sub-class status of icomm is 7 or 8 slots, which is not the expected status.

The structure of the class is described here.
Icomm: communication interface, abstract class
Iserial: serial communication interface, abstract class
Cserial: a serial communication object that implements both the icomm and iserial interfaces (inherited from icomm and iserial)

I initialize it like this:
Iserial * pserial = new cserial (); // Statement 1
Pserial-> setport (4 );
Pserial-> setbaud (19200 );
Icomm * Pcomm = (icomm *) pserial; // Statement 2
// Save pserial and Pcomm

After Statement 2 is executed, the status of the cserial subclass of pserial is Port = 4 and baud = 19200, but that of the cserial subclass of Pcomm is not!

Change Statement 2:
Icomm * Pcomm = (cserial *) pserial;
And run-time check failure #0 disappears.

Analysis: If the conversion path is incorrectly specified when the parent class subclass is converted to another type, the sub-class status and function entry address of the object will be misplaced, therefore, the heap pointer is lost during runtime type check, rather than inconsistent function call conventions.

This error occurs because I am not familiar with C ++ type conversion. I have been using the C type conversion style. I assume that C ++ will help us to fully convert the Parent and Child types. I will review the C ++ type conversion later.