9

I have a class declared in the following way:

#ifndef MYCLASS_H
#define MYCLASS_H

class MyClass : public MyOtherClass
{

public:
    MyClass();

    int a() const{ return _a; };
    int b() const{ return _b; };

private:
    int _a;
    int _b;
};

inline bool operator==( const MyClass& lhs, const MyClass& rhs )
{
    return (lhs.a() == rhs.a()) && (lhs.b() == rhs.b());
}

#endif

My problem is that any breakpoints is set in the overloaded operator== never get hit, with Visual Studio even telling me that execution will never reach this function. I've followed this rule of thumb for overloading comparison operators, but it doesn't mention anything other than to make them non-members, so I'm not sure if I've missed something with operator overloading or inline functions.

Can anyone tell me why my breakpoints are never being hit?

Community
  • 1
  • 1
  • Were you running your code under debug mode when setting those breakpoints? – RoundPi Oct 16 '12 at 09:53
  • I have tried VC10 and it certainly let me get into operator==() no problem at all. Under debug mode you should be able to get into that as others has mentioned. Which version of Visual studio are you using ? – RoundPi Oct 16 '12 at 10:09
  • I'm using VS2010, and I've managed to get it working. They weren't being hit because I was forgetting to dereference my pointers when comparing :) –  Oct 16 '12 at 10:19

3 Answers3

17

Your breakpoints are never hit because the compiler is inlining the code. To set a breakpoint inside that inline function could mean setting hundreds or thousands of "virtual" breakpoints. Keeping track of what code is inlined where is just too much work for the IDE to be doing so, as a result, it doesn't.

To get round the issue either run in debug (where inlining won't, I think, occur) or don't inline the function.

You can also compile with the /Od flag to disable inlining as well as all other optimisations (which is what it does in debug).

Setting the /Ob0 flag should disable inlining from occurring. For performance reasons, however, its advisable to not do this often so you really are best off running in debug.

Goz
  • 61,365
  • 24
  • 124
  • 204
  • Thanks a lot for your answer. I was actually running it under debug mode and the breakpoints were still not being hit. Is there something else that needs to be done? I'm using Visual Studio 2010. –  Oct 16 '12 at 10:04
4

Since OP mentioned he was using debug mode with VS, I have tried to replicate this & it can be replicated.

1>Remove /ZI flag  (no debug infomration) but set it /Zi instead.
2>Disable /Od flag (so no inline) & set it to /Od2.

And this way you can add normal breakpoint cannot get into the inline function breakpoint as its really being inlined.

So Chris Wilson, could you go to your project property and make sure you have 

1>/ZI flag is set.
2>/Od flag is disabled.

If you don't know how to do it, check those two MSDN links below for those two flags.

http://msdn.microsoft.com/en-us/library/47238hez(v=vs.71).aspx

http://msdn.microsoft.com/en-us/library/958x11bc(v=vs.80).aspx

RoundPi
  • 5,819
  • 7
  • 49
  • 75
  • If you have /ZI turned off it probably isn't inlining but without debug info you can't set breakpoints as you don't have a PDB ... – Goz Oct 16 '12 at 10:27
  • @Goz: If you set /Zi (not /ZI) & disable /Od, you can put breakpoint but not in inline function.That's how I replicated OP's issue under debug VC10. – RoundPi Oct 16 '12 at 10:41
0

inline doesn't mean that function body will be inlined in every call site. Actually, function can be inlined by the compiler even if it is not explicitly defined inline. And one function can be inlined in one call site and called normally in another call site. This directive is just a hint to the compiler. Visual studio debugger works fine with inlined functions.

I think this problem doesn't caused by the inline directive. Try to remove this directive and run your code under debugger. And it is very handy to write unit test for cases like this.

Evgeny Lazin
  • 9,193
  • 6
  • 47
  • 83