12

In this question the author of the accepted answer does not recommend the usage of the input operator, because:

operator>> is subject to iomanip stream manipulators and other "funny" stuff, so you can never be sure that it does what's advertised.

But what does it mean? Why should we avoid the input operator of the C++ when we are programming in C++?

The books I have read from The Definitive C++ Book Guide and List did not mention this, they introduced and used the input operator. I have not found anything useful in this topic on the internet neither.

Thanks!

p.s: I am sorry, but I do not have enough reputation to ask my question in that topic.

Community
  • 1
  • 1
Gabor Meszaros
  • 1,335
  • 1
  • 15
  • 25
  • 2
    Well there is no issue, as far as i didn't faced any in the many years that I have been coding. What the author of that answer is suggesting (may be experience) is that it "may/can" cause an unexpected result while inputting values from file. But in my opinion that is not the case, so you can use it as you want to. – Kamran Khan Jan 16 '14 at 07:18
  • I don't see any warnings in the answer. Can you post an exact link on the comment or on the post? Maybe accepted answer changed? – Mikhail Jan 16 '14 at 07:21
  • @Mikhail It's in a comment from another answer http://stackoverflow.com/a/21099735/498298 – hansmaad Jan 16 '14 at 07:24
  • [@H2CO3](http://stackoverflow.com/users/529758/h2co3) should come and answer this. – herohuyongtao Jan 16 '14 at 07:27
  • @kamran Yes, this is my experience also. If you use the input operator then you have to manage and test the states of the input object (e.g. std::cin) which is not needed when you use only the `getline()` function. But that is the way how the input operator works. If you have to parse lines every time when you have to deal with input, it also has disadvantages. – Gabor Meszaros Jan 16 '14 at 07:29
  • Because it was a hideous kludge that should never have been allowed to pollute the C++ space as a primary example of how to misuse operator overloading. My 2c. – user207421 Jan 16 '14 at 09:31

2 Answers2

3

The only things I can think of are the fact that operator>> retains a lot of settings between uses. For example:

std::ifstream fin("input.txt");
std::string str;
double num;

someOtherFunction(fin);

while (fin >> str >> num)
{
   //do something
}

looks pretty innocent unless we consider:

void someOtherFunction(std::ifstream& fin){
    fin.width(1); 
    fin.setf(/* some flags here */); 
    //...
}

I personally read the file raw and do parsing with regex but I am by no means an expert on the subject so that advice should be taken with a big grain of salt.

odinthenerd
  • 5,422
  • 1
  • 32
  • 61
  • I see, it is a good example. Nevertheless I think the problem is more likely with the input stream and not with the input operator. The books I mentioned in the question recommend to design every functions which use streams in a way to store the state of the stream at the beginning of the function, change the state which is suits to the task and then reset the state of the stream at the end of the function. – Gabor Meszaros Jan 18 '14 at 12:41
-3

If the user input length is larger than the allocated buffer, this could lead to a buffer overflow. Hackers may use this in order to overwrite the return address and run malicious code.

Uri Y
  • 840
  • 5
  • 13
  • Could you please explain this in the context of the input operator? – Gabor Meszaros Jan 16 '14 at 08:02
  • If you're directing the input into `char str[80]` then the hacker may write malicious code (assembly) in the beginning of the string and at position 80 he'll put the relative address of -80 so when your function exists it will run his code. – Uri Y Jan 16 '14 at 08:13
  • @Dieter Lücking - Why is it unrelated? He wants to know why is it not recommended to use the input operator. – Uri Y Jan 16 '14 at 08:18
  • That's why you write `out.width(80)` before `out >> str`. – Simple Jan 16 '14 at 08:18
  • @Simple So you have to do extra work to be on the save side? Or do the proposed alternatives do have the same issues (without extra work)? I think with a bit of editing this answer might still get a positive rating ... – TobiMcNamobi Jan 16 '14 at 10:03
  • @TobiMcNamobi you have to set the width when reading into a `char*` (and by extension a `char[N]`). From what I've gathered, people are recommending not to use `operator>>` because flags may be set. In which case, you should change the flags at the entrace to your function and revert them on exit. [See here](http://www.boost.org/doc/libs/1_55_0/libs/io/doc/ios_state.html) for an example. – Simple Jan 16 '14 at 10:58