0

Answered at the bottom. Thanks!

The compiler caught error C2039 and C2065 correctly in Release version;

I'm just curious why the same code CAN pass compile in Debug version?

Is it a known Microsoft bug?

I know DECLARE_DYNAMIC/IMPLEMENT_DYNAMIC will solve the issue. However, without them, why Microsoft passed compile in my debug version? This is the question.

Known the reason. Michael's answer is exactly correct. _AFXDLL is only defined on my Debug configuration. So on Debug version it is using CObject::GetThisClass when expand the macro RUNTIME_CLASS.

So following code will be caught compiler error for both Release and Debug version if DECLARE_DYNAMIC/IMPLEMENT_DYNAMIC were not declared:

CRuntimeClass* p = (CRuntimeClass*) (&XXX::classXXX);

But following code will only fail if _AFXDLL is not pre-defined.

p->IsKindOf(RUNTIME_CLASS(XXX))

Thanks

milesma
  • 1,561
  • 1
  • 15
  • 37
  • 1
    Can you post the source code and show the text of the error messages? – Roger Rowland Jun 26 '13 at 06:45
  • error C2039: 'classXXXX' : is not a member of 'XXXX' and error C2065: 'classXXXX' : undeclared identifier – milesma Jun 26 '13 at 06:51
  • 1
    Is it just me, or is SO being flooded with questions that simply don't have any reasonable level of effort put into them to even make them answerable? – Michael Burr Jun 26 '13 at 06:52
  • I know DECLARE_DYNAMIC/IMPLEMENT_DYNAMIC will solve the issue. However, without them, why Microsoft passed compile in my debug version? This is the question. – milesma Jun 26 '13 at 06:52
  • You've tagged this with MFC, in which case I know there is lots of code `#ifdef DEBUG` etc. - without seeing the code, you've no chance at all of anyone helping answer your question. – Roger Rowland Jun 26 '13 at 06:53
  • @MichaelBurr unfortunately it's not just you [sigh] ... slowly losing the will to live ... – Roger Rowland Jun 26 '13 at 06:54
  • @milesma: please post an example of the code that produces the problem you're asking about. Ideally, it will be short but still compete enough that someone could copy-n-paste it into an editor and compile it to see the effect you're describing. – Michael Burr Jun 26 '13 at 06:58
  • @MichaelBurr: I've updated a sample code. Again, I know how _DEBUG and DECLARE_DYNAMIC/IMPLEMENT_DYNAMIC works; I digged into the source code of those macro bug there is no _DEBUG at all. This surprised me. I'm thinking it is related with pre-compiled header option but not sure. That's why I comes here in case someone experience this "issue"; (Actually, I don't have any issue to fix, just curious.) – milesma Jun 26 '13 at 07:04

1 Answers1

1

A likely explanation is that your debug project configuration is linking to the MFC DLL runtime while your release configuration is linking to the static MFC runtime. When building against the MFC DLL the CObject base object definition in afx.h has the following lines enabled due to the _AFXDLL macro being defined (which indicates that the MFC DLL is being used):

#ifdef _AFXDLL
    static CRuntimeClass* PASCAL _GetBaseClass();
    static CRuntimeClass* PASCAL GetThisClass();
#endif

So, when _AFXDLL is defined, all objects derived from CObject get a static GetThisClass() function, which is what RUNTIME_CLASS() ends up calling if there isn't a better match introduced by a DECLARE_DYNAMIC().

If _AFXDLL is not defined, the GetThisClass() function is not declared in CObject - to get one for the class you must use the DECLARE_DYNAMIC() macro and use IMPLEMENT_DYNAMIC() to get a definition.

So the difference probably isn't a debug vs release, it's a MFC DLL vs MFC static runtime difference.

Michael Burr
  • 333,147
  • 50
  • 533
  • 760
  • I'm not sure what you mean by toggling "_DEBUG to NDEBUG" and vice versa. – Michael Burr Jun 26 '13 at 15:04
  • Know the reason. Your answer is exactly correct. _AFXDLL is only defined on my Debug configuration. So on Debug version it is using CObject::GetThisClass when expand the macro RUNTIME_CLASS. – milesma Jun 26 '13 at 23:22