Noah Roberts wrote:
I have a class, that inherits from a class that inherits virtually from
another class. I have a breakdown occuring and it is not wrt the
virtually inherited class but one of the other MIed pure virtual
classes.
I get this in my call stack at the point of explosion:
Flo.exe!DDocument::Dispatch(DFZone * ptr=0x0298d260) Line 94 + 0x32
bytes C++
Flo.exe!DDocument::Dispatch(DFZone * __A0=0x0298d260) + 0x2f
bytes C++
Flo.exe!DDocument::ReadDocumentItem(DType type=DT_ZONE,
DispatchAcceptor * & LinkParent=0x01ce8c98, int & ctPipes=0x00000000,
TangCount & DiskCount={...}, CDisk & disk={...}) Line 4534 + 0x17
bytes C++
Notice the second to the last call, the first call to something called
Dispatch. This function has no code to look at. It alters the object
pointed to by __A0 such that further up in the second call to Dispatch
things explode. It writes to pointers that should be null at this
point data that is apparently outside the program's memory space. This
function simply doesn't exist anywhere in code and has no line
information. Notice the name __A0, this is apparently an
implementation defined function and I have no idea why.
This only happens when a particular, and unrelated, class is inherited
virtually.
The compiler is MSVC++ 8 (VS2005). I will attempt to put up some code
that exhibits the problem, if I can, tomarro...for now I'm just
currious if anyone has seen this before and can identify what kind of
problem I am experiencing.
I found my problem. I don't know why the Dispatch function has two
calls, one for an implementation defined version of the function but it
seems to only happen when I use the reoccuring template pattern
previous in the MI list to the DispatchAcceptor class (the interface
that defines those functions). I narrowed down the occurance of that
function to those cases but it wasn't causing a problem. No matter
what I did I couldn't recreate the problem...because I don't do silly
things like the following...it is so outside my methods now that I
didn't even think to try...
My problem was caused by C-Style casting. Someone had attempted
something akin to this in a header file:
#include "LinkObj.h"
class N;
class D
{
public:
LinkObj * Dispatch(N * n) { return n; }
};
Now, N is a LinkObj, everone reading the code knows this. However, the
compiler doesn't know it at this point so it demanded a cast. The
developer in question decided, "Ok, I'll cast it then," instead of
wondering why it needed one.
So they used a C-style cast:
LinkObj * Dispatch(N * n) { return (LinkObj *) n; }
BANG, reinterpret_cast to 'unrelated' pointer resulting in undefined
behavior when the developer was obviously desiring a static_cast.
Later, I came along and started introducing MI to pull out
responsibilities in a refactor session. Went from undefined behavior
that worked to undefined behavior that did really rediqulous things,
like altering user defined pointers to point at virtual tables.
So kiddies, that just goes to show that you should never use C-Style
casts...ever. We have better casting options for a very good reason.
Undefined behavior can do ANYTHING...and can cost hours of trouble
tracking down.
As soon as I put the desired cast in there, just for a test, the
compiler puked. As soon as I moved the definitions from the header to
a cpp with knowledge of all types the sytem quit exploding and doing
wierd things. This cost my employer many dollars in hours I speant
trying to figure this out as well as a couple hours of a fellow
developer working with me to try and find the prob. C++ casts require
about 20 seconds, tops, to type and very little research on how to use
them and save many, many hours of work...use them.
I am currious why there is an extra, implementation defined, version of
the Dispatch function when I use the CRTP and inherit from that before
the one defining the dispatch function but as long as I don't introduce
UB it still works. The debugger won't step into it or anything past
that call so I'll avoid this situation when I can but it works 'as if'
so doesn't violate the std. Just a curriosity. Interestingly the
implentation defined vtbl goes away in that super class under these
conditions and is replaced by these funky function calls.
