Thread: Very weird pointer error in 2005 in release

While in the process of compiling my game engine thus far into a static lib I ran into a very strange error.

The declarations in my class are:

Code:

...
DXInput *m_pInput;
DXMouse *m_pMouse;
DXKeyboard *m_pKeyboard;
...

And the code to new them up is:

Code:

...
m_pInput = new DXInput();
if (!m_pInput)
{
    return false;
}
m_pInput->Init(m_hAppInstance);

m_pKeyboard = new DXKeyboard();
if (!m_pKeyboard) 
{
    return false;
}
m_pKeyboard->Init(m_pInput,m_hAppInstance,m_hwndAppWindowHandle);

m_pMouse = new DXMouse(m_pInput->GetInterface());
if (!m_pMouse) 
{
    return false;
}
m_pMouse->Init(m_hwndAppWindowHandle);
...

The errors in release mode - and only in release mode:

1>..\src\D3DApp.cpp(61) : error C2440: '=' : cannot convert from 'DXInput' to 'DXInput *'
1> No user-defined-conversion operator available that can perform this conversion, or the operator cannot be called
1>..\src\D3DApp.cpp(64) : error C2440: '=' : cannot convert from 'DXKeyboard' to 'DXKeyboard *'
1> No user-defined-conversion operator available that can perform this conversion, or the operator cannot be called
1>..\src\D3DApp.cpp(71) : error C2440: '=' : cannot convert from 'DXMouse' to 'DXMouse *'
1> No user-defined-conversion operator available that can perform this conversion, or the operator cannot be called

Release build wants me to put the address of operator before the new but debug build then throws up this which is expected:

1>e:\dev\x3dlib\src\d3dapp.cpp(61) : error C2102: '&' requires l-value
1>e:\dev\x3dlib\src\d3dapp.cpp(64) : error C2102: '&' requires l-value
1>e:\dev\x3dlib\src\d3dapp.cpp(71) : error C2102: '&' requires l-value

This is clearly a compiler goof up and I do not know how to get past it.

Damn me if that isn't the weirdest thing.

Are you using templates? Might be a long shot but move the DXInput header file to the top of your includes list and see if that gets you rid of the first error.

EDIT: To clarify, assuming everything is indeed alright with your code, what I'm thinking is you may be able to circumvent this apparent bug by juggling your includes around.

EDIT 2: Do also a full rebuild... are you by chance reusing an old object file that the compiler didn't catch?... I'm fishing here but once I couldn't find a t-shirt anywhere that I had just finished ironing. After going nuts I found it in my freezer. It turns out absent mindedly I left it there when I took the chicken out. nuff said.

Ah. You found your t-shirt!

Originally Posted by Bubba

Code:

...
m_pInput = new DXInput();
if (!m_pInput)
{
    return false;
}
m_pInput->Init(m_hAppInstance);

m_pKeyboard = new DXKeyboard();
if (!m_pKeyboard) 
{
    return false;
}
m_pKeyboard->Init(m_pInput,m_hAppInstance,m_hwndAppWindowHandle);

m_pMouse = new DXMouse(m_pInput->GetInterface());
if (!m_pMouse) 
{
    return false;
}
m_pMouse->Init(m_hwndAppWindowHandle);
...

Why you don't destroy anything before the return statement?

Nope it will just crash which will take about 1 minute to find and fix. That was not the point of this thread, however. The error has been fixed and now it works just fine.

Why you don't destroy anything before the return statement?

And the code to new them up is:

Why do you assume I have to destroy anything in this section of code? I gave you no indication as to where this code was but if you must know it is the setup for the system. Wouldn't do much good to destroy what I just created. If I was really concerned with checking the pointers, and I'm not, I would not use raw pointers and would switch to boost pointers. If you cannot get directinput, the mouse, or the keyboard up and running the system is dead in the water anyways and the only way to recover would be to exit...which is going to happen if it crashes.

Cmon, now don't be too harsh on him, anybody can write a piece of code in which 45% will never ever execute. I'm sure it's great in other areas.

Originally Posted by Bubba

Even my crappy little D3D framework...

Oh...

Originally Posted by Bubba

Why are you quoting items that are not in this thread?

There's no need to get defensive... It's natural for any good programmer, when looking at a piece of code, to point out potential problems. If I were looking at that piece of code during a review I'd be asking the same questions -- where are those allocations handled if a failure occurs?

This week at work I spent a total of about 10 hours defending my code in code review. (I mean "defending" in the sense of a Ph.D thesis, not that people were attacking my code.) It was exhausting, but I'm glad we did it, as it found a few problems I hadn't seen.

Not getting defensive. Feel free to critique the code or do whatever makes you feel happy and I'll move on to other things. I did not ask for a code review and when the answer was found I stated it very clearly meaning I thought the discussion was over. If I wanted a code review maybe I would have titled the thread something along those lines. But if you want to review it feel free - if that's what really gets you going then go for it.

We all have code reviews and we all learn from them but this thread is not a code review. However if you wish to review my code then perhaps I will post some of it in a thread and get your take on it. I'm certainly not above learning.