Debuging by value

  • Thread starter Thread starter Jason
  • Start date Start date
J

Jason

In the c++ debugger I could give it a memory address of some data and it
would break when that data changed. It is very helpful when you have a
single value change of a large amount of code and you just want to know
what/where/why its changing. I tried to hook it up like I in C++, opening up
the new break point window, going to the data tab and supplying a pointer...
just for fun I put in the var name ( since there are no pointers in c# ) hit
ok and I got the message.

"C# does not support Data Breakpoints"

Is there some other way of achieving the same task? Like I said it is
immensely helpful in some debugging situations, usually the worst
situations.
 
That type of scenario sounds like overuse of global varaibles. Turn your
variable into a property and on it's set metod put your break point, then
you know when it is getting changed.
 
Jason,

You've touched on one of my few gripes about C#.

Inexplicably, C# does not support data breakpoints. I was astounded that
such an incredibly useful capability is absent in C# when it's been
supported by other Microsoft debuggers for years (FoxPro, for instance).

Actually the debugger seems rather lame in evaluating expressions generally.
Frequently, perfectly valid expressions (often easy ones, such as
someString.Length > 0) are rejected by the debugger. This needs fixing.

In the meantime you just have to kludge this sort of thing into your code:

#if DEBUG
if (Debugger.IsAttached == true && someCondition == true) {
Debugger.Break();
}
#endif

--Bob
 
Please excue my ignorance, but if the changing points
of data are well defined ( e.g. using OOP's properties or just set and get
methods) why would there be a need to this type of debugging?
This type of problem belongs to users of Global Variables.
Please correct me if I am wrong
 
You are correct, sort of. By that I mean that if I were not using an
accessor it would be a problem of inadequate design. In this case however I
am using a class and property accessor that is very frequently used. The
problem is I want to know when a specific instance of a classes specific
value has changed, which is the real power of debugging by value (another
big one is catching memory leaks ). Also the problem is that the property in
question is a sealed microsoft class ( GraphicsPath ) and I have no way of
putting a break point exactly where I want it, tho I do have accessors to
access those accessors.

Jason
 
Yes, it seems really silly, tho there is probably a reasonable ( to
someone ) explanation for why it is.

Unfortunatly I dont think that the conditional approach you listed will work
for me in this case. Ideally I want to be able to tell when a value has
changed in a specific instance. If I was using only 1 instance it would not
be such a pain. Its only in the interactions of all these instances it
occurs so ripping stuff apart to widdle it down to a few instances is more
work that I would like to do ;) plus it might invalidate the situation the
bug is occuring in.

Jason
 
It is and I did, but it gets hit a few hundred times by other classes that
inherit from the same base class.
 
btw, what are your other gripes.. just curious.


Bob Grommes said:
Jason,

You've touched on one of my few gripes about C#.

Inexplicably, C# does not support data breakpoints. I was astounded that
such an incredibly useful capability is absent in C# when it's been
supported by other Microsoft debuggers for years (FoxPro, for instance).

Actually the debugger seems rather lame in evaluating expressions generally.
Frequently, perfectly valid expressions (often easy ones, such as
someString.Length > 0) are rejected by the debugger. This needs fixing.

In the meantime you just have to kludge this sort of thing into your code:

#if DEBUG
if (Debugger.IsAttached == true && someCondition == true) {
Debugger.Break();
}
#endif

--Bob
Click to expand...
 
Back
Top