views:

21

answers:

2

I ran into a rather odd behavior that I don't even know how to start describing. I wrote a piece of managed C++ code that makes calls to native methods.

A (very) simplified version of the code would look like this (I know it looks like a full native function, just assume there is managed stuff being done all over the place):

int somefunction(ptrHolder x)
{
  // the accessptr method returns a native pointer
  if (x.accessptr() != nullptr) // I tried this with nullptr, NULL, 0)
  {
    try
    {
      x->doSomeNativeVeryImportantStuff(); // or whatever, doesn't matter
    }
    catch (SomeCustomExceptionClass &)
    {
      return 0;
    }
  }

  SomeOtherNativeClass::doStaticMagic();

  return 1;
}

I compiled this code without optimizations using the /clr flag (VS.NET 2005, SP2) and when running it in the debugger I get to the if statement, since the pointer is actually null, I don't enter the if, but surprisingly, the cursor jumps directly to the return 1 statement, ignoring the doStaticMagic() method completely!!!

When looking at the assembly code, I see that it really jumps directly to that line. If I force the debugger to enter the if block, I also jump to the return 1 statement after I press F10.

Any ideas why this is happening?

Thanks, Ariel

+1  A: 

Did you try checking that code is actually emitted for the SomeOtherNativeClass::doStaticMagic(); line? Perhaps the compiler couldn't find it (or finds an empty function or something like that) and therefore skips it.

Second idea: Perhaps you are comparing two things which can't be compared by using nullptr. So you get an exception, which is caught and causes you to exit the method directly.

Daniel Rose
You were right about this. Managed C++ behaves weirdly when an exception is thrown and not handled, the execution jumps to the last return line, what makes it look confusing in the debugger.
Sakin
+1  A: 
Mr Roys