Handing over an object to an overloaded operator

Question

Someone gave me an error program yesterday. Working in MVS 2010, I found a problem and an alternative for it. The problem was the overloaded class input statement. His prototype was as follows ...

void matrix :: operator << (matrix&) ; 

He was called from somewhere like this ...

 matrix m ; m.operator << (m) ; 

I decided that the compiler does not allow sending the same object as the reference parameter to which the function was called. But I do not understand the reason for this and what it creates. I would be grateful if anyone could explain this. Thanks.

EDIT: Actually, what happens is that after debugging, it enters the function, exits, and when main executed, it goes to the external dependency file dbgdel.cpp and stops at this line.

  _ASSERTE(_BLOCK_TYPE_IS_VALID(pHead->nBlockUse)); 

Answer 1

The above code compiles and works fine in VS2010 SP1 .

There are no problems with the code, as shown, this is completely legal. It's a little strange for me to declare operator overloading and then call it with the << operator, since you could just write m << m .

Some assumptions:

• You take the address m somewhere in the operator implementation and accidentally delete it
• You overlap the boundaries of the array of values ​​that are likely to be stored in the matrix inside the operator implementation.
• There is a discrepancy in the assumptions of the compiler and linker between the calling code and the called code. Check your calling conventions, the version of the run-time libraries on both sides, and any other parameters such as SECURE_SCL and debugger interceptor.

Answer 2

In a method that implements operator << , be sure to check for self-promotion:

 void matrix :: operator << (matrix& other) { if (this == &other) { /* special processing */ } else { /* regular code */ } } 

Answer 3

It seems that your program tells you that the heap is damaged: at some point, it crossed the boundaries of the array or wrote to memory through a freed pointer or something like that.

These errors can be difficult to track because you don’t know exactly when it happened, but it is very likely that it happened in another place where the error appeared. There is no problem using reference parameters as you have them.

There are tons of suggestions on how to spot tons of corruption here:

Heap damage under Win32; how to find?