cin question

[Eli_1]

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?

[Maddox]

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.

[iago]

You can do it using threads for sure, but that becomes difficult.  I think there is a better way, but I'm not sure.

[Adron]

I know of no standard way of doing it. In Windows, I'd msgwaitformultipleobjects on among other things a console input handle.

[j0k3r]

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.

[Maddox]

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.

[Kp]

Creating 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.

[iago]

Using a floating textbox might also work for you.  Hopefully Adron will see this and give some sort of detail on that one

[Adron]

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.

[Eli_1]

Ok thanks, I'll look around for that.

[Eli_1]

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.

[iago]

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

[Adron]

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

[DVX]

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)

[iago]

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.