Question on how to make Visual C++ console programs not close the console window after running...

Hello,

I've been teaching an Intro to C++ class (for engineers and scientists) that uses g++ on Linux. We generally spend 1-1.5 lectures going over Linux commands and running g++ before really delving into the C++ programming language. Throughout the course, people repeatedly ask about how to get Linux commands to work for different things they're doing because they're new to Linux and because they have no incentive to "really" learn Linux. g++ also has a lot of standards violations by default - static arrays with variable size instead of constant size, not passing type double to a parameter in a cmath function, and omitting return statements in functions that are not void.

I was wanting to recommend to the course coordinator that we switch to Visual C++ in order to avoid dealing with Linux commands, in order to have better standards compliance, and in order to take advantage of other easy-to-use Visual C++ features like popup warnings about additional code problems.

I've found that if you create a console program in Visual C++, by default in debug mode it closes the console window after the program ends. This would cause students a lot of confusion. If I instruct them to place a break point at the end of the program, a lot of them are going to be confused. Control + F5 seems to alleviate this, but I've seen some forum posts saying it sometimes doesn't work on systems.

Is there any way to get the debug mode run with F5 to keep the console window open afterwards? If it involves configuration, this would have to be done on everyone's machines, which would probably require the department tech people to do it.

Should control + F5 always work to keep the console window open afterwards?

Does anyone know of any other Visual C++ issues to watch for?
If you're not going to use breakpoints, then it sounds like you're not going to use the debugger. Ctrl + F5 sounds like the way to go. I don't know what you mean when you say, "it sometimes doesn't work on systems." I don't think using the debugger is confusing, though. It would be great to see more students get debugger exposure earlier.
Should control + F5 always work to keep the console window open afterwards?

Does anyone know of any other Visual C++ issues to watch for?


Ctrl+F5 will work in VS if the program is configured to be a console program. If left unspecified, it will still close immediately, even if you Ctrl+F5.


Right click on your project in the solution explorer (side panel), go to properties.

> Configuration Properties
> Linker
> System
There's a "SubSystem" option. Make sure that's set to "CONSOLE"

Apply, rebuild, Ctrl+F5, and now it should stay open.


It would be great to see more students get debugger exposure earlier.


Yes yes yes. It should be the absolute first thing taught. Students should be stepping through a hello world app in a debugger line by line from day 1.
add

system("pause");

before return 0;
add

system("pause");

before return 0;

Head, meet desk..
> g++ also has a lot of standards violations by default
> static arrays with variable size instead of constant size,
compile with -pedantic-errors. That would reject forbidden extensions

> not passing type double to a parameter in a cmath function,
┬┐? I don't follow
`cmath' is a c++ header. c++ allows function overloading, and a lot of function are in fact overloaded for float double and long double

> and omitting return statements in functions that are not void.
a warning at most.
-W{all,extra,pedantic,error}


> I was wanting to recommend to the course coordinator that we switch to Visual C++
> (...) in order to have better standards compliance
┬┐wasn't Visual C++ the one that allowed to call `main()' and to declared it as void main() ?


> It would be great to see more students get debugger exposure earlier
even before input/output
let them explore the values and set them through the debugger.
g++ also has a lot of standards violations by default
If g++ violates some standards, MSVC compilers violate double that, on top of not supporting half of the C++11 features g++ does.

we switch to Visual C++
I wouldn't do this for two reasons.
1.) MSVC compilers are lagging so far behind in the C++11 game. You'll be forced to teach students workarounds or old methods instead of using the most up-to-date standard's capabilities.
2.) Compiling on linux (or any OS, I say linux because doing anything with the command line in windows is just god awful) via the command line creates an intuition for how things work behind the curtain. IDE's are fantastic, but they don't help you with this intuition, which I find to be really helpful.

The only problem here is that the command line lacks a GUI debugger.

The point of my argument is not necessarily to dissuade you from using MSVC, just to make you consider the options and tentative pitfalls of doing so.
IMO Visual Studio is a phenomenal IDE. I spent most of my junior years coding in it until I got to the point where I simply couldn't overlook it's lack in support. I just wish it's compilers didn't suck.
Topic archived. No new replies allowed.