![]() |
|
#1
|
|||
|
|||
fast characters in consoleHello,
I want to use a console application on linux, but with a more responsive stdin/stdout interface. Like it is now, I can read input (getchar()) and write output (printf("%c",c)), but this only works after a CR. So characters are only read in after I press the 'enter' key of the keyboard. Also when printing, the characters are viewed only after a "\n". I'm not a linux programmer, but in DOS/WINDOWS, it works a bit different. Can someone put me on the right track? Stefaan |
|||
|
#2
|
|||
|
|||
|
Quote:
Typical Linux implementations do not automatically flush the output buffer until a newline is sent, but you can force it with fflush(). To make sure the output appears on the screen you can do the following: CPP / C++ / C Code:
This also works, but is unnecessary, with Windows console applications, so this code is portable. Non-standard user input (as you indicated that you want to do) is not portable. To capture characters like getch() does in Borland and Microsoft Windows (and DOS, as I recall), here is a possiblity: getch() for Linux Note, that, like the DOS/Windows implementations of getch(), the getch()-like function in the link does not echo the characters, and doesn't automatically take into account user input editing (you would have to capture and handle backspace, escape, ctrl-c, and other special characters normally handled by the shell interface to getchar(), fgets() or scanf()). Regards, Dave Last edited by davekw7x : 20-Jun-2005 at 09:25.
|
|
#3
|
||||
|
||||
|
Quote:
For a string, puts() is a much better choice. The reason is printf() has to do a lot of extra processing trying to figure out how to deal with the format string (%c in this case) and putch() just knows a char is a char. Simple and direct. __________________
During the election they said Obama could only be elected when pigs fly. Well, we currently have an epidemic of Swine Flu. Coincidence? |
|
#4
|
|||
|
|||
|
Quote:
Well, putch() is a non-standard function (the counterpart to getch()), which puts characters to the console without buffering (or so I recall from my days of the original Borland C, on my CP/M system in 1980-something --- it didn't even have a version number, it was just "Turbo C"). The function putch() is not available in my Linux installation, and, frankly, with all of the operating system overhead and other processing going on, I would really doubt that I could measure any performance improvement by streamlining console output or even file I/O. As a matter of fact, every time that I have tried to improve the performance by choosing larger --- or smaller --- buffers for file I/O, I made it worse. You could use C Standard library functions putchar(ch) or fputc(stdout, ch) to put out single characters (rather than printf("%c", ch)) but it still doesn't appear on my Linux screen until a '\n' gets sent (or until fflush(stdout) is executed or other I/O such as getchar() is performed). And let's face it: with console user I/O or file I/O, the bottleneck is the user and/or the I/O channel, not processing power wasted in printf(). I'll grant you that puts(str) may be "better" (more elegant) for strings than printf(str) or printf("%s", str), and it appeals to my often-professed propensity for minimalism. It still requires fflush(stdout) (on my Linux system at least) if the string doesn't end with a '\n'. That was the thrust of my response to one of the questions actually asked by the Original Poster. By the way, did you ever wonder why the first program by K&R and by everyone else since then has always been CPP / C++ / C Code:
1. Why not puts(), if it is really better? Maybe a single function, printf(), that is flexible enough to handle all possible console output is worth learning first? Maybe that is simpler than learning one function for strings, one for characters, and one for numbers or various combinations. I don't know. 2. What about punctuation --- shouldn't it be "Hello, world.\n", or maybe "Hello, World!\n", or something? Regards, Dave "Simplify, simplify!" --- Henry David Thoreau |
|
#5
|
|||
|
|||
|
Hi,
Please don't start a fight on my little example :-) Where is printf spending most of its time? I think on converting numbers to text (printf("%5.3f", d)), not on dumping simple strings. The speed difference on puts, printf is a bit like this I think : - puts(string) : just a simple while loop dumping chars until a 0 char is detected. - printf(string) : just a simple while loop waiting for a 0 char or for a '%' char. If a '%' is found, more processing is needed to handel it of course. - printf("%s", string) : same a s above, but now we have to process the "%s" first, and the specific processing for "%s" is a simple while loop waiting for a 0 char. All these functions are not compatible in any case : puts("shool result : 75%\n") : no problems printf("shool result : 75%\n") : problem : need an extra '%' : "shool result : 75%%\n" printf("%s", "shool result : 75%\n") : no problem For microcontrollers and (slower) embedded systems, the speed difference can be significant. I prefer a smaller version than the C library, because not all the features like floating point are needed. Stefaan |
|
#6
|
|||
|
|||
|
Quote:
As a matter of fact, I don't even link in printf() for small systems (That is, for systems running barefoot --- without an operating system). I typically implement something like puts(), with itoa() or some other number formatting function (and putchar() for characters). I also use assembly language for time-critical or memory-sensitive parts of the application. Your original question was about Linux, which I assumed was not a small system. Regards, Dave (p.s. It wasn't a fight; I assumed that the original questions had been answered, and went off on a tangent with Walt. We do this from time to time, since lots of people other than the Original Posters follow these threads, and I perceive that there are learning opportunities here, even though I usually end up using too many words --- didn't mean to hijack the thread.) |
|
#7
|
|||
|
|||
|
Dave,
I just wanted to point the difference between programming a PC and a small system. Instead of puts() and itoa(), try to automate it with a small custom printf function, it can save you a lot of programming. The number of calculation to be done in itoa are generally the same as in the printf("%d"... just at this moment I noticed something : printf("%c",42) is converted to putchar(42) by the GCC compiler. This surprised me a lot. Stefaan. |
|
#8
|
|||
|
|||
|
Quote:
There are lots of surprises when we look at the tremendous optimizations carried out by modern compilers. Loops are unrolled or otherwise optimized; multiplication by integers is sometimes replaced by shifts and adds; etc. That's why I suggest that people write programs that make sense to them and that are "correct by inspection" and not to spend time and effort in the beginning sweating the "small stuff". Then, when time or memory issues arise, and only then, do I revisit my code to try to improve performance. Regards, Dave |
|
#9
|
||||
|
||||
|
Quote:
__________________
During the election they said Obama could only be elected when pigs fly. Well, we currently have an epidemic of Swine Flu. Coincidence? |
|
#10
|
|||
|
|||
|
Anyway, I'm happy I discovered this forum. I will use it again in the future I think, and i will try every now and then to help some people if I can.
Stefaan |
Recent GIDBlog
Accepted for Ph.D. program by crystalattice
| Thread Tools | Search this Thread |
| Rate This Thread | |
|
|
Similar Threads
|
||||
| Thread | Thread Starter | Forum | Replies | Last Post |
| Re: Things to Avoid in C/C++ -- gets() , Part 1 | WaltP | C Programming Language | 5 | 21-Jun-2007 13:13 |
| How to interpret characters as they are being entered? | nkhambal | C Programming Language | 18 | 14-Feb-2006 11:41 |
| Windows XP - Graphics in DOS console? | LeFunkster | C Programming Language | 5 | 14-May-2005 01:01 |
| Can you change the background colors in a console app? | swashplate | C++ Forum | 3 | 07-Dec-2004 21:19 |
Network Sites: GIDNetwork · GIDWebHosts · GIDSearch · Learning Journal by J de Silva, The