I am new to C++ programing and to this forum. I just finished Java Programing in college (good riddance), and now I am on to C++, which seems to be a bit easier to understand.
I saw and read the thread about Keeping the Console Open, and, frankly, I am terrified to post anything in that thread. I am a bit nervous even bringing it up here, but I cannot find a satisfactory answer to this. Here goes:
I know one can keep a console window open by using system("Pause"). In fact, I know that there are several ways to do this. Keeping in mind that I have not yet covered "running programs from the command line" yet and that my grasp of C++ is still a bit shaky, what is the standard for keeping the console window from immediately shutting down once it has performed its task?
For my last homework assignment, I used system ("Pause"), but I would like to know if there is already a function in the libraries that is designed to do this. If using system("pause") is a bad practice, then I don't want to make a habit of it, even if it is only for homework assignments.
If it was me, I would design a little loop that checks for key input. Of course, I would go super low level for this and use assembler but that can get messy.
I think that people should start including their operating system when approaching subjects like this.
I have dual boot Ubuntu and Windows Vista on my laptop, so I'll give you a miniature explanation for each.
Windows: Navigate to the program using 'cd' in command prompt, and run it in there. This will result in the command prompt staying open after your program has completed.
Ubuntu: I'm in love. Any IDE, or Compiling/running in the terminal. No matter what, it stays open without any commands.
There is no 'command' for keeping a window open. There is a command for closing the window, which is what is being sent to the console when you program ends, so to speak.
If you run from the command line, it will stay open. This is actually pretty simple. Just open the console, navigate to your program's folder (use 'cd') and then type your program's name.
@Disch: How do you recommend running/testing CONSOLE programs without the CONSOLE?
@LadyKrimson: Np! There are no 'universal' commands, but I do recommend using an IDE/Compiler! I use Code::Blocks and love every bit of it! http://www.codeblocks.org/
This allows you to create your program (.cpp file), build, compile, and run! In addition, it has its own console (or at least the Linux version does) that doesn't require any additional commands to wait!
++ If you decide to use Code::Blocks, get the MinGW(Minimalist GNU for Windows) version!
Sorry, Disch. For most of my assignments, I'll be using the console.
Zhuge, there is a command for closing the window? Where is this command? Is it an OS command?
ProgrammingNoob, I am using Visual Studio 2010. That is the program required for the course. Is there a "Code::Blocks" add-on (so-to-speak) for Visual Studio?
No, there is no 'add-ons' to implement Code::Blocks. However, I will tell you that I personally don't think Visual Studio is a good idea/habit. It tends to do big parts of the code for you already, and it's not good learning if you wish to fully understand your codes.
Visual Studio is not something I'd recommend either, but for a different reason. Visual Studio tends to use a slightly different approach to the standard which can eventually lead to the lack of portability of your codes.
It tends to do big parts of the code for you already, and it's not good learning if you wish to fully understand your codes.
Not if you make an empty project.
Visual Studio is not something I'd recommend either, but for a different reason. Visual Studio tends to use a slightly different approach to the standard which can eventually lead to the lack of portability of your codes.
Such as?
GCC has just as many flaws when it comes to being not-quite-exactly-standards-compliant.
While not ideal, Visual Studio is what you are required to use, right? I'd keep the warnings presented here in mind, even if you don't heed them.
With that said, I'm glad you are choosing to follow good practices rather than bad ones. system("pause") is nice, but you can find plenty of alternatives. Some work better than others while still others don't work at all. For example, Visual Studio still provides a header regarded as antiquated and generally bad: <conio.h>. You can use a while loop to check for keyboard input via the kbhit() function provided (or _kbhit() as your compiler might recommend). Unfortunately, that is not portable. Move to a different platform such as Apple's Mac OS X or GNU/Linux, and you won't have that. In fact, you won't have system("pause") either!
The lesson: keep your mind open and remember that some things you do aren't always portable like system("pause").
Disch, GCC sure has other-not-quite-compliant implementations. But what I'm trying to get to is portability. GCC works on most, if not all, platforms. If there are non-standard implementations, at least the code is still portable. Visual Studio only works on Windows and any learned "limitation" will only ever work on that platform, decreasing portability.
But what I'm trying to get to is portability. GCC works on most, if not all, platforms. If there are non-standard implementations, at least the code is still portable.
Properly written code can be compiled on any compiler. If you want to preach about code portability, the right way to do it would be to encourage writing standards compliant code and/or test compiling with multiple compilers.
When you speak in terms of portability, you kind of have to test compile on multiple compilers anyway. How can you know if you code really is portable unless you compile it for multiple platforms? And as long as you're compiling it for multiple platforms, why not use multiple compilers in the process?
In my book, something that compiles only on GCC isn't any better or worse than something that compiles only in MSVS.
Although I admit you somewhat have a point... but it's like a twisted, corrupt point. It's like euthanizing someone with a fatal disease. You can argue "it's okay because they're going to die anyway", but it still leaves a bad taste in my mouth.