views:

256

answers:

1

I'm using VS2010 Ultimate. Having code:

//file IntSet.h
#include "stdafx.h"
#pragma once
/*Class representing set of integers*/
template<class T>
class IntSet
{
private:
 T** myData_;
 std::size_t mySize_;
 std::size_t myIndex_;
public:
#pragma region ctor/dtor
 explicit IntSet();
 virtual ~IntSet();
#pragma endregion
#pragma region publicInterface
 IntSet makeUnion(const IntSet&)const;
 IntSet makeIntersection(const IntSet&)const;
 IntSet makeSymmetricDifference(const IntSet&)const;
 void insert(const T&);

#pragma endregion
};

//file IntSet_impl.h
#include "StdAfx.h"
#include "IntSet.h"

#pragma region ctor/dtor
template<class T>
IntSet<T>::IntSet():myData_(nullptr),
     mySize_(0),
     myIndex_(0)
{
}

template<class T>
IntSet<T>::~IntSet()
{
}
#pragma endregion

#pragma region publicInterface
template<class T>
void IntSet<T>::insert(const T& obj)
{//BREAKPOINT---------------------------<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
/*IF I SET A BREAKPOINT HERE AND AFTER THAT I CHANGE SOMETHING IN THE BODY 
    I'M GETTING MSG SAYING THAT THE BREAKPOINT WILL NOT CURRENTLY BE HIT, AFTER I REBUILD 
    THE BREAKPOINT IS VALID AGAIN*/

 /*Check if we are initialized*/
 if (mySize_ == 0)
 {
  mySize_ = 1;
  myData_ = new T*[mySize_];
 }
 /*Check if we have place to insert obj in.*/
 if (myIndex_ < mySize_)
 {
  myData_[myIndex_++] = new T(obj);
  return;
 }

 /*We didn't have enough place...*/
 T** tmp = new T*[mySize_];//for copying old to temporary basket
 std::copy(&myData_[0],&myData_[mySize_],&tmp[0]);
 delete myData_;
 auto oldSize = mySize_;
 mySize_ *= 2;
 myData_ = new T*[mySize_];
 std::copy(&tmp[0],&tmp[oldSize],&myData_[0]);
 myData_[myIndex_] = new T(obj);
 ++myIndex_;
}
#pragma endregion

See linke marked as BREAKPOINT. Thanks.

+4  A: 

If you change the code while the program is running, the code no longer matches what was compiled, so the debugger is (usually) unable to manage breakpoints until the program is stopped and rebuilt with the new source.

Under some circumstances, Visual Studio supports edit-and-continue debugging where you can edit a file while the debugger is stopped at a breakpoint, then when you resume it will recompile that code and resume with the modified code.

James McNellis
Yes but I'm not changing the code while debugger is running.
There is nothing we can do
Since everybody closed this, I can't post a *proper* answer. I THINK all you're seeing is that the breakpoint tooltip thing is just out-of-sync because the background compiler hasn't fully caught up with your changes. I've seen this happen a LOT where the breakpoint icon makes me THINK it won't work but once I start debugging, then it will turn into a filled circle again and it will actually work. I just ignore it and assume it's a Visual Studio bug.
Jaxidian
@Jaxidian Thanks for your answer, but in my case it just skips this breakpoint (do not enter the fnc body).
There is nothing we can do
@Jaxidian Personally I think that is a bug and I'm going to report that behaviour to VS Team.
There is nothing we can do
@Jax is right. You're using templates, an after changing those you often need to force a proper re-compile. @Knowing: Something as trivial as a breakpoint probably isn't broken. Assuming it's a bug in the IDE/compiler is the last thing you should be doing.
GMan
@Knowing: If you have made a change and haven't recompiled, why would you even expect it to hit that breakpoint? At that point, your code doesn't match your assembly, and when you're in that state, I wouldn't expect predictability.
Jaxidian