# Double or more statements in one line, how does the debugger behave?

This topic is 2059 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

n+=2; Func(n);

If two statements are typed in the same line, how does this affect the debugger? Since the debugger
picks line numbers apparently(in GDB and the Visual Stuido debugger)

##### Share on other sites
The debugger jumps to the code marked as being on the next line. It's not aware of C statements, just the line information of the source. Note, this is the same information that the processor macro __LINE__ outputs, meaning that it can be modified with #line statements.

##### Share on other sites
n+=2; Func(n);
If two statements are typed in the same line, how does this affect the debugger? Since the debugger
picks line numbers apparently(in GDB and the Visual Stuido debugger)

in my experience with the VS debugger, if you have a single line (with multiple statements), it is treated as a single unit (for things like single-stepping, ...), but if spread over multiple lines, then each will executed individually.

this has the result that how things are formatted will effect how stepping works:

for(i=0; i<1000; i++)DoSomething();

vs:

for(i=0; i<1000; i++)

DoSomething();

where the former will be stepped over all at once, but the latter will involve needing to step through each iteration of the loop.

an exception seems to be function calls, which IME seem to (normally) always behave as a single unit (although it is possible to step-into called functions and similar within argument lists).

##### Share on other sites
function call results are used as parameters

Do you mean actual parameters(AKA arguments)?

##### Share on other sites

function call results are used as parameters

Do you mean actual parameters(AKA arguments)?
Sorry, yes.

Basically the line:

SomeObject x = foo ( someThing.GetPart(), otherThing.DoStuff().ModifyResult() );

could potentially cause your debugger to stop multiple times on the line if you are stepping through the debugger. The debugger gets to choose what it means.

The debugger might step over the entire line in one step.
The debugger might stop execution many times as it goes through each of the function calls, maybe even stopping before running x's constructor.

The debugger get to decide whatever it means to step over something.

##### Share on other sites
You can always drop down the assembly level if you specifically need to break in between the two statements, in case it matters. Debuggers don't actually work with source code or care in the least about it. It's just the UIs (be it a CLI or GUI interface) that interface with the code and take the concepts you as a programmer mostly deal with (lines in files) and map those to assembly instructions. Likewise, you can debug binaries without debug information, it's just (often significantly) harder because you're stuck manually correlating things in the assembly to the original source.

##### Share on other sites

This causes me to think, is there a standard for debuggers?

Searching a while at stackOverflow.com seemed to throw no meaningful results.

Edited by gasto

##### Share on other sites

This causes me to think, is there a standard for debuggers?
Searching a while at stackOverflow.com seemed to throw no meaningful results.

Standard for _what_ in debuggers?

Different OSes expose different debugging-relevant features in different ways. Different hardware exposes debugging features in different ways. Different executable formats encode their debug-symbol information in different ways. Different programming languages and runtimes have different semantics that can be debugged and different ways of being hooked into by a debugger.

##### Share on other sites

This causes me to think, is there a standard for debuggers?
Searching a while at stackOverflow.com seemed to throw no meaningful results.

Standard for _what_ in debuggers?

Different OSes expose different debugging-relevant features in different ways. Different hardware exposes debugging features in different ways. Different executable formats encode their debug-symbol information in different ways. Different programming languages and runtimes have different semantics that can be debugged and different ways of being hooked into by a debugger.

Hence the question, why do programming languages possess a standard but debuggers don't?

• ### Game Developer Survey

We are looking for qualified game developers to participate in a 10-minute online survey. Qualified participants will be offered a \$15 incentive for your time and insights. Click here to start!

• 11
• 15
• 21
• 26
• 11