Safe alternative to 'cin'?

[datta016]

So I've been trying to get into Embedded Systems programming, specifically using VxWorks and Windriver 3.0. Now, these two aren't necessarily friendly toward the <iostream> library (unless you create your own BSPs != portability), and so I've been sticking only to <stdio.h>. I understand that with embedded systems there aren't too many times where a program will need to use 'cin'-like functions, and as for an alternative to 'cout', 'printf()' has been working just fine (minor learning hiccups along the way, but it's all good).

Regardless, for my own curiosity I was hoping the cplusplus community may be able to provide me with a decent alternative to 'cin' preferrably included in the <stdio.h> library. I have checked sources like google and have only come up with gets(), but those same sources say never to use it.

So to sum up. Can anyone provide me with a 'cin' alternative that can be used exclusively wtih <stdio.h> that isn't as frowned upon as gets()?

[helios]

scanf() is basically equivalent to std::cin. It sucks approximately as hard.

Why do you even need stdin in an embedded system? It doesn't make sense.

[NoobsDeSroobs]

Why do you say it sucks?

[helios]

Which one?

With scanf(), one mistake and you can easily produce a buffer overflow or a segmentation fault. If the program doesn't crash immediately, it will some undefined time in future.
std::cin leaves trailing whitespace in the input buffer, which in some cases (I haven't used it enough to know when, exactly) has been known to create infinite loops and similarly serious problems.

I don't know which I hate more.

[kempofighter]

Rarely do I use cin, cerr, or cout directly in an embedded system but they could be used. At the very least, you'd typically have some kind of logging framework for capturing error or debug info but ultimately they are either captured by some tool monitoring a network (where the messages are datapumped across a wire where they are visible to the tool) or they are sent to cout or cerr. There are so many flavors of embedded OS's, compilers, boards, probes, and so forth it is very difficult to give you any specific advice. For some embedded systems you might have a tool that connects a debugger to the software running on the target and the std output stream is sent through the debugger, somehow. You'd have to read the documentation for the tools, contact customer support, or fiddle with it to figure out what you can do in your environment. I've never used vxworks, personally. Using cin is even rarer, but I have done it for test drivers where I want to be able to connect to a test driver via a debugger and type in the test case number that I want to run. Then again, if you have a way of sending messages to the program that would be better. At the very least, never use the input/output streams directly. Try to create some kind of wrapper so that you can write your code to that interface and then you can fiddle with the implementation details later.

[kempofighter]

std::cin leaves trailing whitespace in the input buffer, which in some cases (I haven't used it enough to know when, exactly) has been known to create infinite loops and similarly serious problems.

That problem is fairly easy to rectify although there are so many tools and options it is easy to forget which one to use at any given time. What's wrong with the getline function or simply using the ignore function to eliminate the unneeded data in the input stream? I agree with you though, cin is really frustrating sometimes especially for beginners who aren't aware of the gotcha's. Thankfully I rarely need to use it. However, I would always choose the C++ iostream library over the c libraries any day of the week.

[helios]

What's wrong with the getline function

Absolutely nothing. I was talking specifically of std::cin >>something;
I encourage using std::getline() whenever it's necessary to get console input.

or simply using the ignore function to eliminate the unneeded data in the input stream?

That's one more extra step than absolutely necessary. I'm well aware of it, but why should I have use it? It's ridiculous. I understand that it's meant to allow inputting things like "1 2 3 4", but let's face it: how often do you absolutely need to enter more than one datum per line? Wouldn't it be a lot more useful and intuitive for std::cin to behave like std::getline()?

[jloundy]

getline() ?
its preferred over cin anyways

[NoobsDeSroobs]

So how can you use getline() to identify a string?

[firedraco]

What do you mean by "identify a string"?

Example usage:

std::string MyString;
std::getline(std::cin, MyString);
//do stuff with MyString 

[NoobsDeSroobs]

To differ between functions.

Like if "Quit" is written then, quit the program. If jump is written, then the character jumps. etc.

You are using cin there. std::getline(std::cin, MyString);

[wmheric]

Oh c'mon, cin >> is different from getline(cin, MyString), which is also different from cin.getline()...at least they come from different places, so when you say getline() do you mean the global function from the Strings library or the istream member function?

Btw, cin is just an istream object, there is no particular problem if one is "using cin".

[datta016]

Hey everyone,

Sorry I was away for the weekend and was without Internet so I did not get a chance to check out the forum until today. First off, I just would like to thank everyone for taking a look at this and giving me their input.

Also, just to clarify, as mentioned in my original post:

I understand that with embedded systems there aren't too many times where a program will need to use 'cin'-like functions

This was merely to expand my knowledge on programming in C/C++. As there is a cout alternative in using printf() I was just wondering if there were something similar for cin without having to use <iostream>. Thankfully you've been able to provide me with what I was looking for.

Again, thanks to all. Much appreciated.