I have a class in a .h file:
class Blah
{
public:
Blah(){}
virtual ~Blah(){}
void WriteMessage( bool MessageReceived )
{
if(MessageR
I would suggest you firstly Delete the output files : Physically delete all generated DLLs, PDBs and EXEs. Then compile (rebuild) again to generate the files. Sometimes Visual Studio can "get lost" and "forget" to overwrite the output files when you build your solution.
This can happen for a few other reasons:
I wound up having this issue too, the context of my app was a main app in C# which used unmanaged C++ code in a lower layer that I wanted to step into from the debugger. From the C# project properties I went into the Debug tab and under the Enable Debuggers section checked the "Enable unmanaged code debugging".
Wanted to mention that I experienced the "Breakpoint will not be hit..."
error when porting some of my older MFC (managed--using clr support)
projects into VS2015
.
What fixed the issue for me was setting this:
Configuration Properties\Linker\Debugging\Debuggable Assembly
... to this:
Yes (/ASSEMBLYDEBUG)
If you are using CLion, try adding -DCMAKE_BUILD_TYPE=Debug
to your CMake options:
For me, the answer was:
Project Properties->C/C++->Optimization
Set Optimization to : "Disabled (/Od)"
I had the same issue but the accepted solution of cleaning up files didn't work for me. I have my issue resolved and it had to do with my code. Here are the details of my fix, hope it gives some clues to your fix.
What I was doing is overloading CArchive
<<
operator for my structure but the code never steps into it. I would set the break point and I got the solid red symbol. As soon as I start debugger the symbol becomes outlined and the warning message on it says:
The breakpoint will not currently be hit. no executable code is associated with this line
My relevant code is below where the break point doesn't break.
class Book
{
friend CArchive& operator << (CArchive& ar, const Book & book )
{
ar << book.title;
ar << "\r\n";
ar << book.price;
ar << "\r\n";
}
}
Now there is an obvious problem with this code is that it doesn't have a return statement return ar
but the compiler never complained. The reason compiler didn't complain was I was using the operator incorrectly (and rather never using it)
book *mybook = new Book(...);
ar << mybook;
Because mistakenly I am accessing the operator via pointer, my object's <<
operator was never really invoked and that's why compiler didn't complain either because it was never being used.
So first I fixed the calling code
book *mybook = new Book(...);
ar << *mybook;
Now the operator overloading method complains about the return
statement and I fixed that too.
I can now step into the function. So the bottom line was that the break point was not being set because this code was essentially sidelined by compiler (correctly) because it was never used in the code.