Solve : C++ 6.0 - Console Program write to file causes cout display te

1.	Solve : C++ 6.0 - Console Program write to file causes cout display text to vanish?
Answer» I have a C++ 6.0 program that displays to the user in the dos shell ( console program ) as to what it is doing, but instead it displaying what is happening as I would expect to have happen, the text flashes for a second and then I get a flashing cursor until the outside secondary process is complete at which point the text I wanted to have DISPLAYED to let the user know what process is happening is displayed. I am guessing that it may be because I am executing a secondary process outside of the primary program, at which maybe I need to edit the secondaries to display what is happening instead of the primary program. Is there a method to keep the displayed text in the primary program without having to go through editing all of these MANY outside process programs that the primary program calls to execute? Here is a small example of code cout<<" Display this information to user\n"; system("running_outside_process_in_another_lang uage.exe"); You could try cout.Flush() before calling the external programThanks, I'll give that a try!You can also try: #include system("cls"); but you should only use this if your alreay including windows otherwise its a waste of space Quote from: Khasiar on May 26, 2011, 11:52:00 PM You can also try: #include <windows.h> system("cls"); but you should only use this if your alreay including windows otherwise its a waste of space several points: 1. the system call is part of the C standard library. there is no need to include windows.h to use it. 2. cls probably doesn't fix the problem, since the problem is that the expected text is appearing later than expected, not that it's appearing and it's not wanted. 3. (purely IMO, and perhaps more general). using functions to execute external programs to perform "core" functionality demonstrates absolutely nothing but a lack of research. For example, take using system("cls"). First, off, that is only going to work on a windows/DOS machine. running that on a nix machine will not work since the proper command for that is clear. "so add conditionals" you might say. true, but why do all that when you can just use scrclr(); from the C Standard library (conio.h) to clear the screen? Or you could use any number of console I/O libraries such as ncurses. Additionally, a good rule of thumb is that unless you are a front-end for some other application or the application you are creating is specifically designed for executing some other program, you shouldn't use system at all, much less for basic things like "pause" and "cls" and so forth. some possible responses: "well golly gee BC, I use it and it get's the job done, what's wrong with that". Well yes, of course it works- for you, at that particular moment, on that particular system. The entire purpose of writing a C++ program as opposed to say a batch program is to get better portability, faster SPEED, and a more diverse programming environment, but when you use the system() call (and this counts for the equivalents in other languages, such as Shell() and exec() and all that) you are basically saying "I'd much rather be writing a batch script, I only wrote this so I can say I wrote it in C++". "But it's code reuse!" No, it's not. for one thing, most of the things you would use system() for (ASIDE from of course if your application is designed to run an external program) are either present as part of the standard library of nearly any Console-capable language, and those are aren't available are easily built from that. Whatever the arguments for using System() are, they are far outweighed by the cons. for one thing- using system almost always makes you dependent on a platform. Now again that may bring up the "well I just needed it quickly", and that seems reasonable, but when your C++ program is merely a loop making a few system() calls, you may as well have created it as a batch file to begin with. Especially since using a series of System() calls is slower than just using a batch script, so there goes one (mostly dubious) advantage. Not to mention writing said batch script would be orders of magnitudes faster then writing, linking, and compiling a C++ program that simply calls system a few times. -It's resource heavy. Think about it. system() basically executes not just one, but maybe two separate processes (the command interpreter and then the other program, for example) and returns an exit status to your program (hopefully the exit status from the program you are attempting to run). Not to mention everything that could go wrong. the user could not HAVE that program, they could be on a separate OS using a different command interpreter that doesn't understand the syntax, or doesn't posess the inbuilt commands you assume exist everywhere (using system("cls") on a nix machine, for example). And what if the user doesn't have permission to execute the command? What then? how do you handle errors? of a system("cls") call fails, what do you do? not clear the screen? show an error? Really, I can't even understand why anybody would ever use system() for this type of thing, nor why it seems so popular (for hobbyist programmers, presumably professional/experienced programmers use system() when they want to start an external program, not just because they want to clear the screen) Let's take another common example: system("pause"). Yes- it will pause a program. This pause can be helpful if the IDE you are using to TEST your program doesn't insert it's own "implied" pause or doesn't keep the window open when your application finishes so you can see the results. But really, using system("pause") is like burning your GPS unit when you are lost on a desert island to make smoke signals. Many people- and this includes so-called "instructors" who are supposed to know what they are doing but seldom do (that's why they are instructors, and not actually working in the industry, but I digress) for some inexplicable reason they believe that making a call to the command interpreter (cmd, bash, what have you) and running a system command to temporarily halt a program is a good thing. In the words of Babbage, "I cannot rightly apprehend the confusion of ideas that leads to such a conclusion". First, as I've already noted, it's not portable. system("pause") only works on DOS/Windows Machines, and no others. Second, as I also noted- it's very resource heavy. system() suspends your program, makes a call to the Operating System, which often relaunches the command interpreter as a sub-process (or child process on windows), the command interpreter parses the command, searches for the appropriate program, allocates memory to run said program, passes that program any arguments you gave, monitors the program's Process to wait until it exits, free the memory it allocated for running the program and returns the exit code to your program, having to perform similar cleanup for any processes that were spawned in the process. One problem with this approach is that it makes for a built-in security flaw. Both systems can have their search path's hijacked and built in tools can be replaced locally with compromised ones. Arguably by that time the user has lost, but if your program is run with root privs and you shell out to some other application at any point, you better make damned sure if you use any user input it's well protected against buffer overflows, and even then you have to make sure the rest of your application is safe from buffer overflows as well because a clever hacker could easily just add a few nop sleds and mess about with memory in such a way that your system() call in one part of your program can have it's arguments changed merely because you used a printf() call with a single argument and using user input. Considering all these problems, and the fact that there are much cleaner ways included in the language itself that make all this unnecessary, you have to include headers you otherwise might not need (if you are "properly" programming in C++ you shouldn't be using or conio), in the end it's just a bad habit that you'll have to break away from eventually anyway. I mean, really, how is system("pause") really that much easier then Code: [Select]printf("Press any key to continue..."); getch(); It's not, it merely indicates a clear lack of research into their problem. "oh, I need to clear the screen, oh hey, I can use system and I know the OS has a "cls" command I can use! YAY" A quick google for "Clear screen with C++" or "Clear screen with C" presents a multitude of solutions... although the ratio to those that suggest the use of system() in some way is dismally high. Many good points BC, noted

Solve : C++ 6.0 - Console Program write to file causes cout display text to vanish?

Answer»

I have a C++ 6.0 program that displays to the user in the dos shell ( console program ) as to what it is doing, but instead it displaying what is happening as I would expect to have happen, the text flashes for a second and then I get a flashing cursor until the outside secondary process is complete at which point the text I wanted to have DISPLAYED to let the user know what process is happening is displayed.

I am guessing that it may be because I am executing a secondary process outside of the primary program, at which maybe I need to edit the secondaries to display what is happening instead of the primary program. Is there a method to keep the displayed text in the primary program without having to go through editing all of these MANY outside process programs that the primary program calls to execute?

Here is a small example of code

cout<<" Display this information to user\n";
system("running_outside_process_in_another_lang uage.exe");
You could try cout.Flush() before calling the external programThanks, I'll give that a try!You can also try:

#include

system("cls");

but you should only use this if your alreay including windows otherwise its a waste of space Quote from: Khasiar on May 26, 2011, 11:52:00 PM

You can also try:

#include <windows.h>

system("cls");

but you should only use this if your alreay including windows otherwise its a waste of space

several points:

1. the system call is part of the C standard library. there is no need to include windows.h to use it.

2. cls probably doesn't fix the problem, since the problem is that the expected text is appearing later than expected, not that it's appearing and it's not wanted.

3. (purely IMO, and perhaps more general).

using functions to execute external programs to perform "core" functionality demonstrates absolutely nothing but a lack of research. For example, take using system("cls"). First, off, that is only going to work on a windows/DOS machine. running that on a *nix machine will not work since the proper command for that is clear. "so add conditionals" you might say. true, but why do all that when you can just use scrclr(); from the C Standard library (conio.h) to clear the screen? Or you could use any number of console I/O libraries such as ncurses.

Additionally, a good rule of thumb is that unless you are a front-end for some other application or the application you are creating is specifically designed for executing some other program, you shouldn't use system at all, much less for basic things like "pause" and "cls" and so forth.

some possible responses:
"well golly gee BC, I use it and it get's the job done, what's wrong with that".
Well yes, of course it works- for you, at that particular moment, on that particular system. The entire purpose of writing a C++ program as opposed to say a batch program is to get better portability, faster SPEED, and a more diverse programming environment, but when you use the system() call (and this counts for the equivalents in other languages, such as Shell() and exec() and all that) you are basically saying "I'd much rather be writing a batch script, I only wrote this so I can say I wrote it in C++".

"But it's code reuse!"
No, it's not. for one thing, most of the things you would use system() for (ASIDE from of course if your application is designed to run an external program) are either present as part of the standard library of nearly any Console-capable language, and those are aren't available are easily built from that.

Whatever the arguments for using System() are, they are far outweighed by the cons. for one thing- using system almost always makes you dependent on a platform. Now again that may bring up the "well I just needed it quickly", and that seems reasonable, but when your C++ program is merely a loop making a few system() calls, you may as well have created it as a batch file to begin with. Especially since using a series of System() calls is slower than just using a batch script, so there goes one (mostly dubious) advantage. Not to mention writing said batch script would be orders of magnitudes faster then writing, linking, and compiling a C++ program that simply calls system a few times.

-It's resource heavy.

Think about it. system() basically executes not just one, but maybe two separate processes (the command interpreter and then the other program, for example) and returns an exit status to your program (hopefully the exit status from the program you are attempting to run). Not to mention everything that could go wrong. the user could not HAVE that program, they could be on a separate OS using a different command interpreter that doesn't understand the syntax, or doesn't posess the inbuilt commands you assume exist everywhere (using system("cls") on a *nix machine, for example). And what if the user doesn't have permission to execute the command? What then? how do you handle errors? of a system("cls") call fails, what do you do? not clear the screen? show an error?

Really, I can't even understand why anybody would ever use system() for this type of thing, nor why it seems so popular (for hobbyist programmers, presumably professional/experienced programmers use system() when they want to start an external program, not just because they want to clear the screen)
Let's take another common example: system("pause").

Yes- it will pause a program. This pause can be helpful if the IDE you are using to TEST your program doesn't insert it's own "implied" pause or doesn't keep the window open when your application finishes so you can see the results. But really, using system("pause") is like burning your GPS unit when you are lost on a desert island to make smoke signals. Many people- and this includes so-called "instructors" who are supposed to know what they are doing but seldom do (that's why they are instructors, and not actually working in the industry, but I digress) for some inexplicable reason they believe that making a call to the command interpreter (cmd, bash, what have you) and running a system command to temporarily halt a program is a good thing. In the words of Babbage, "I cannot rightly apprehend the confusion of ideas that leads to such a conclusion".

First, as I've already noted, it's not portable. system("pause") only works on DOS/Windows Machines, and no others. Second, as I also noted- it's very resource heavy. system() suspends your program, makes a call to the Operating System, which often relaunches the command interpreter as a sub-process (or child process on windows), the command interpreter parses the command, searches for the appropriate program, allocates memory to run said program, passes that program any arguments you gave, monitors the program's Process to wait until it exits, free the memory it allocated for running the program and returns the exit code to your program, having to perform similar cleanup for any processes that were spawned in the process. One problem with this approach is that it makes for a built-in security flaw. Both systems can have their search path's hijacked and built in tools can be replaced locally with compromised ones. Arguably by that time the user has lost, but if your program is run with root privs and you shell out to some other application at any point, you better make damned sure if you use any user input it's well protected against buffer overflows, and even then you have to make sure the rest of your application is safe from buffer overflows as well because a clever hacker could easily just add a few nop sleds and mess about with memory in such a way that your system() call in one part of your program can have it's arguments changed merely because you used a printf() call with a single argument and using user input. Considering all these problems, and the fact that there are much cleaner ways included in the language itself that make all this unnecessary, you have to include headers you otherwise might not need (if you are "properly" programming in C++ you shouldn't be using or conio), in the end it's just a bad habit that you'll have to break away from eventually anyway. I mean, really, how is system("pause") really that much easier then

Code: [Select]printf("Press any key to continue...");
getch();

It's not, it merely indicates a clear lack of research into their problem. "oh, I need to clear the screen, oh hey, I can use system and I know the OS has a "cls" command I can use! YAY" A quick google for "Clear screen with C++" or "Clear screen with C" presents a multitude of solutions... although the ratio to those that suggest the use of system() in some way is dismally high.

Many good points BC, noted

Solve : C++ 6.0 - Console Program write to file causes cout display text to vanish?

Discussion

No Comment Found

Related InterviewSolutions

Reply to Comment