Console app... fyi
I wanted to know if it was possible to get user input while other things are happening... such as receiving data and displaying it... I can't really use cin.getline() because when my loop hits that it won't move on and display everything. is there a way around this or is it impossible with console apps?
Quote from: Eli_1 on February 09, 2004, 07:45 PM
Console app... fyi
I wanted to know if it was possible to get user input while other things are happening... such as receiving data and displaying it... I can't really use cin.getline() because when my loop hits that it won't move on and display everything. is there a way around this or is it impossible with console apps?
I know that on unix based operating systems you would use fcntl() but I'm not sure if this works on windows.
You can do it using threads for sure, but that becomes difficult. I think there is a better way, but I'm not sure.
I know of no standard way of doing it. In Windows, I'd msgwaitformultipleobjects on among other things a console input handle.
I know how to do this in another programming language, and it's from a loooong time ago... Multithreading is not something very hard in that language, but I don't know much about C++ and so couldn't tell you how to do it.
Quote from: j0k3r on February 09, 2004, 10:12 PM
I know how to do this in another programming language, and it's from a loooong time ago... Multithreading is not something very hard in that language, but I don't know much about C++ and so couldn't tell you how to do it.
Creating a new thread with CreateThread() is not too difficult but it seems like overkill for what he is doing.
Quote from: Maddox on February 10, 2004, 08:14 AMCreating a new thread with CreateThread() is not too difficult but it seems like overkill for what he is doing.
Also, adding a thread would introduce all sorts of synchonization issues. I say give up cin and use ReadConsoleInput in conjunction with MsgWaitForMultipleObjects (as Adron suggested). ReadConsoleInput is better anyway -- you can get much finer control, and avoid the potential chokeups cin suffers when it gets a datatype it doesn't like.
Using a floating textbox might also work for you. Hopefully Adron will see this and give some sort of detail on that one :)
Quote from: iago on February 10, 2004, 11:51 AM
Using a floating textbox might also work for you. Hopefully Adron will see this and give some sort of detail on that one :)
Haha, floating textbox works fine. You'd want to use the MsgWaitForMultipleObjects technique with that as well, just create the floating input window some time before you enter your main loop.
Ok thanks, I'll look around for that.
Nevermind, I found a CreateThread() example and worked off that and it does exactly what I need. I'll post the code that I used soon as an example to anyone else that doesn't know.
Quote from: Eli_1 on February 11, 2004, 07:01 PM
Nevermind, I found a CreateThread() example and worked off that and it does exactly what I need. I'll post the code that I used soon as an example to anyone else that doesn't know.
Keep in mind there is a lot of overhead stuff happening there, but if you're ok with that then life is good :)
Quote from: Eli_1 on February 11, 2004, 07:01 PM
Nevermind, I found a CreateThread() example and worked off that and it does exactly what I need. I'll post the code that I used soon as an example to anyone else that doesn't know.
CreateThread is fine, but you'll eventually run into synchronization issues. Do share your code though, both for others and for review :)
just my two sense about cin:
cin is worthless in use when you can use an stdio input method for the following reasons: when cin is called it makes a call to a class, which is slightly more overhead than a function call (not really a relevant concern however), you have much finer control with stdio functions than you do with streams, you avoid the potential defects of cin such as giving cin different input than what it expects from the variable you are writing too (your program won't crash if you use stdio method and give a bad input)
Quote from: DVX on February 19, 2004, 09:28 AM
just my two sense about cin:
cin is worthless in use when you can use an stdio input method for the following reasons: when cin is called it makes a call to a class, which is slightly more overhead than a function call (not really a relevant concern however), you have much finer control with stdio functions than you do with streams, you avoid the potential defects of cin such as giving cin different input than what it expects from the variable you are writing too (your program won't crash if you use stdio method and give a bad input)
Granted, but not all stdio functions are good either. gets() and scanf("%s"), for example, can very sasily overflow buffers, but cin >> [std::string]; won't.
Besides, the issue here isn't whether or not he's using cin, take your complaints about it to a different thread.
I'd use fgets(stdin, ...) or cin.getline and parse the line out myself with stuff like strchr/strtok/strtoul.
I would, too. For the assignments I'm marking, most people use either fgets() or getchar(). Both are good.
If you're willing to go Windows-specific, you may be able to get much finer control using ReadConsoleInput and parsing the messages yourself. It's more work, but you'll be able to do things like respond to "special" keystrokes in the stream without the user having to press enter (and afaik there's really no advantage to getchar(stdin) over reading the console directly with WinAPI).
Also, DVX: printf ("%s\n", (char *) 1); /* splat with stdio! */
Quote from: Kp on February 19, 2004, 12:51 PM
If you're willing to go Windows-specific, you may be able to get much finer control using ReadConsoleInput and parsing the messages yourself. It's more work, but you'll be able to do things like respond to "special" keystrokes in the stream without the user having to press enter (and afaik there's really no advantage to getchar(stdin) over reading the console directly with WinAPI).
Also, DVX: printf ("%s\n", (char *) 1); /* splat with stdio! */
well the reason I'm trying to move away from iostream is because I want to be able to make things on a linux machine also...
Quote from: Eli_1 on February 19, 2004, 01:32 PM
Quote from: Kp on February 19, 2004, 12:51 PM
If you're willing to go Windows-specific, you may be able to get much finer control using ReadConsoleInput and parsing the messages yourself. It's more work, but you'll be able to do things like respond to "special" keystrokes in the stream without the user having to press enter (and afaik there's really no advantage to getchar(stdin) over reading the console directly with WinAPI).
Also, DVX: printf ("%s\n", (char *) 1); /* splat with stdio! */
well the reason I'm trying to move away from iostream is because I want to be able to make things on a linux machine also...
You should be able to use STL on Unix...
Quote from: Skywing on February 19, 2004, 01:33 PMYou should be able to use STL on Unix...
Yes, but many versions of gcc tend to be a bit dumb about templates (fails to properly determine which template functions need to be implemented, so it just implements them all). IMO, you're much better off not mixing gcc and templates if you can avoid it.
i was giving my opinion..besides, it doesn't really matter
Quote from: Kp on February 19, 2004, 02:06 PM
Quote from: Skywing on February 19, 2004, 01:33 PMYou should be able to use STL on Unix...
Yes, but many versions of gcc tend to be a bit dumb about templates (fails to properly determine which template functions need to be implemented, so it just implements them all). IMO, you're much better off not mixing gcc and templates if you can avoid it.
Is that any problem other than a size issue? If it only affects size, I wouldn't worry about it, but rely on a newer version of gcc appearing before it becomes a problem.