Geoff <ge...@invalid.invalid> wrote:
> On Wed, 26 Sep 2012 07:54:22 +0000 (UTC), Juha Nieminen
> <nos...@thanks.invalid> wrote:
>>Start your program from Visual Studio by pressing ctrl-F5, and the window
>>will stay open until you press a key.
> That's a nice feature but ctrl-F5 is "start without debugging" while
> F5 is "start debugging".
I really can't understand what's Microsoft's rationale behind having
the pause only when you start in non-debug mode, but you should be
complaining to them...
>>Start your program from Visual Studio by pressing ctrl-F5, and the window
>>will stay open until you press a key.
>That's a nice feature but ctrl-F5 is "start without debugging" while
>F5 is "start debugging".
>The preferred method for most uses of the debugger is to set a
>breakpoint at the expected program termination point. This will keep
>the debuggee window open until the process is terminated by the
>debugger or you execute past the breakpoint. The obvious disadvantage
>of breakpoints is that you have to place them at all the exits if your
>program has more than one.
Still OT, but...
If you set a breakpoint at the beginning of the program*, and then use
ctrl-F5, you'll be able to debug from that point on, and the console
window will stay open at the end. The one downside is that it's tough
to debug things that happen before the first line of main() (such as
the execution of constructors for global objects).
The application does needed to be linked with /SUBSYSTEM:CONSOLE
(which should be there if you started the project as a console
application, but IIRC, the default has changed if you start with an
*empty* project).
This is an annoying property of VS, and has been for many years. The
reason for the difference is that VS runs a "without debugging"
application differently - it actually creates a batch file to run the
program, and puts a "pause" at the end of that, and then runs the
batch file - "with debugging" starts the program directly under the
control of the debugger. Still this is annoying enough that MS should
have found a way to fix it, even though it might require as OS change.
*Alternatively put a DebugBreak() call at the beginning of main(), and
you don't have to remember to manually set the breakpoint there.
Robert Wessel <robertwess...@yahoo.com> wrote:
> If you set a breakpoint at the beginning of the program*, and then use
> ctrl-F5, you'll be able to debug from that point on, and the console
> window will stay open at the end.
If you start with ctrl-F5, no debugger will be attached and all breakpoints
are simply ignored.
The only way to debug is in that case to manually attach the debugger to
the process.
> The one downside is that it's tough
> to debug things that happen before the first line of main() (such as
> the execution of constructors for global objects).
> The application does needed to be linked with /SUBSYSTEM:CONSOLE
> (which should be there if you started the project as a console
> application, but IIRC, the default has changed if you start with an
> *empty* project).
If you compile/link without /SUBSYSTEM:CONSOLE, you don't even have a
console. If you don't have one, you shouldn't care much whether it will be
closed or not.
> This is an annoying property of VS, and has been for many years. The
> reason for the difference is that VS runs a "without debugging"
> application differently - it actually creates a batch file to run the
> program, and puts a "pause" at the end of that, and then runs the
> batch file - "with debugging" starts the program directly under the
> control of the debugger. Still this is annoying enough that MS should
> have found a way to fix it, even though it might require as OS change.
Put a breakpoint on the closing brace of main(), and the console will stay
open. Where's the problem?
> *Alternatively put a DebugBreak() call at the beginning of main(), and
> you don't have to remember to manually set the breakpoint there.
Which I'd consider even worse than putting getc() at the end of main().
