breakpoint traps on wrong line (msvc 7.1)

[Jay]

Guess this has probably been reported already. Seems if you don't use {}
with for/while etc., the debugger stops at the wrong line. In the example
below, I had a breakpoint at line 6 but the debugger stopped in every
iteration of the loop.

Jay

1. for (int index=0; index < line_buffer.Length (); index++)

2. if (line_buffer [index] == '\t')

3. line_buffer [index] = ' ';
4. // }}}

5. //
6. terminator_holding_chars = ""; // <- breakpoint here

[David Lowndes]

>Guess this has probably been reported already. Seems if you don't use {}

with for/while etc., the debugger stops at the wrong line. In the example
below, I had a breakpoint at line 6 but the debugger stopped in every
iteration of the loop.

Jay,

Are you debugging a debug or release build of your code?

You should certainly expect strange behaviour debugging a release
(optimised) build.

Dave
--
MVP VC++ FAQ: http://www.mvps.org/vcfaq

[Jay]

"David Lowndes" <da****@mvps.org> wrote in message
news:ou********************************@4ax.com...

Guess this has probably been reported already. Seems if you don't use {}
with for/while etc., the debugger stops at the wrong line. In the example
below, I had a breakpoint at line 6 but the debugger stopped in every
iteration of the loop.

Jay,

Are you debugging a debug or release build of your code?

You should certainly expect strange behaviour debugging a release
(optimised) build.

Dave
--
MVP VC++ FAQ: http://www.mvps.org/vcfaq

This is definitely the debug configuration. Sure I'd expect an optimizing
compiler to do very peculiar things to the code (I know, I write them :-).
This isn't a serious problem, but I noticed in previous versions, when using
single step the debugger appeared to go to strange places sometimes,
particularly with switch statements. I think what's happening is that the
compiler inserts an extra 'dummy' statement at the end of a for loop so that
you can see the consequences of the last statement

e.g. in

for (;;)
{
bool ok = f (x);
}

you wouldn't be able to see the 'ok' value (with single step) unless there
was some other statement following it.

Now, in the example above, you can put a breakpoint on the '}' which works
fine. The problem is if you don't use {}, the debugger gets confused where
this dummy statement is e.g.

1. for (;;)
2 bool ok = f (x);
3.
4. int a=1;

The debugger *should* recognise that it's ok to put the dummy statement (and
indeed a breakpoint) at line 3 (i.e. at the *end* of line 2) but I guess it
has certain rules that prevent this. So it moves it to line 4. Consequently,
if you really intended to put the breakpoint at line 4, the compiler tests
it for a breakpoint in the loop and traps there by mistake.

Anyway, I don't know how the compiler team have implemented this so I'm
guessing a bit and if you ask them, you might well get the answer it's 'by
design' as it might be quite awkward to change.

Jay

[David Lowndes]

Jay,

You're right.

As a proponent of always putting in the curly brackets, I've never
noticed this myself.

Let's see if someone from MS spots your post and gives us the nitty
gritty, if they don't, I'll try to raise your question with them.

As you say, it's probably "by design", but it's best to be sure.

Dave
--
MVP VC++ FAQ: http://www.mvps.org/vcfaq

[Ronald Laeremans [MSFT]]

Yes, this is a known issue, it should be fixed in the Whidbey release. I'll
have someone verify that it is.

Ronald Laeremans
Visual C++ team

"David Lowndes" <da****@mvps.org> wrote in message
news:og********************************@4ax.com...

Jay,

You're right.

As a proponent of always putting in the curly brackets, I've never
noticed this myself.

Let's see if someone from MS spots your post and gives us the nitty
gritty, if they don't, I'll try to raise your question with them.

As you say, it's probably "by design", but it's best to be sure.

Dave
--
MVP VC++ FAQ: http://www.mvps.org/vcfaq