Evil

**laserlight** · 06-25-2008

Why not just split the discussion?

Good point.

Actually, it's cin >> that I consider a problem, not the >> overloaded operator.
We can overload >> for many classes and give them a good purpose.
But cin or wcin... that's where I draw the line to unuseful and misguiding use.

Consider standard I/O redirection and pipes.

Except it's less of a hassle to just check if a conversion failed rather than checking and clearing the input buffer.

That's true, though for some command line programs invalid input would result in immediate termination.

**Daved** · 06-25-2008

>> Otherwise, might we just spell it differently? Discouraged, perhaps?
Yes, that's the whole point- spell it differently. If I was trying to give the advice you're giving (which I don't necessarily agree with) I would say, "Be careful when using cin >> because it does not read spaces and has other issues that might cause you problems. Consider using getline instead."

>> But cin or wcin... that's where I draw the line to unuseful and misguiding use.
This shows a misunderstanding of the concept. cin and wcin are just streams like any other stream. The same issues you have with cin>> would apply to fin or sin (where those are an ifstream and istringstream respectively). The problems you describe are products of operator>> itself and how it works on built-in standard C++ types.

**Elysia** · 06-25-2008

Originally Posted by laserlight

Good point.

It's something I tend to do when a discussion rails of the original discussion

Consider standard I/O redirection and pipes.

Hmmm.
But even with redirection, you would still be reading the input as char[] with cin, wouldn't it?
Same with pipes.
I've only used them to redirect a stream to a pipe where I read strings from. I don't know if there are other possibilities.

That's true, though for some command line programs invalid input would result in immediate termination.

But still, as they say, isn't it better that the program itself handle the termination instead of calling abort() by the library?

Originally Posted by Daved

>> Otherwise, might we just spell it differently? Discouraged, perhaps?
Yes, that's the whole point- spell it differently. If I was trying to give the advice you're giving (which I don't necessarily agree with) I would say, "Be careful when using cin >> because it does not read spaces and has other issues that might cause you problems. Consider using getline instead."

That's why I suggested that the use of cin >> is discouraged.
I like to label some functions from which I see no apparent purpose as "discouraged" or "evil," since it would put those functions in the right category (as "gets" is evil and should never be used, just not used for this specific purpose).

>> But cin or wcin... that's where I draw the line to unuseful and misguiding use.
This shows a misunderstanding of the concept. cin and wcin are just streams like any other stream. The same issues you have with cin>> would apply to fin or sin (where those are an ifstream and istringstream respectively). The problems you describe are products of operator>> itself and how it works on built-in standard C++ types.

No, not really.
Being able to overload operator >> is nice and fine, and you can control its usage, as well.
What I simply don't agree with is that cin >> doesn't read whitespace. If it read entire lines, I wouldn't have a problem with it.

**Daved** · 06-25-2008

>> No, not really.
You didn't contradict my statement. If the problem is not reading whitespace, it has nothing to do with cin. That happens by default with any input stream that uses a standard C++ operator>>.

>> That's why I suggested that the use of cin >> is discouraged.
Thank you. I appreciate it when people can admit when they were wrong or could have said something differently. BTW, there is a big difference between "discouraged" and "evil".

There is also a difference between "discouraged" and "I discourage". The former implies it is generally advised against, the latter implies that you generally advise against it. In this case I'm not sure the former is appropriate, since I've only seen one other person ever actively discourage the use of operator>>.

**whiteflags** · 06-25-2008

>> But even with redirection, you would still be reading the input as char[] with cin, wouldn't it? Same with pipes.

The important distinction being that it wouldn't necessarily be appropriate to consume more of the file on the event of a failed read (like you would if cin were reading the keyboard) and some other action, like an exception being raised, would be appropriate. So you shouldn't give crit as if reading the keyboard were the only way to use cin. cin>> is a string reader that splits strings by white space. Asking people to dupe that functionality when they need it wouldn't be my choice unless I could give my reasons why cin>> is not appropriate, rather than just appraising the whole I/O library. Much more reputable IMO.

**Daved** · 06-25-2008

>> you would still be reading the input as char[] with cin, wouldn't it?

I glossed over this before, but you do realize that cin >> works with the C++ string class, right?

**Thantos** · 06-25-2008

Originally Posted by Elysia

Then what is the official definition of evil?
To me, it's a function that does not do what you expect it to do. Therefore, it is evil.

So let me get this stright: It is evil because you don't understand how it'll work? Is the ^ operator evil because it doesn't do power?

I consider the behavior of

Code:

int i;
string s;

cin>>i>>s;

with an input of "513s hello" to be worse then it not including spaces.

Regexps are great but they can be a lot slower then simple validation and often is just plain overkill.

**phantomotap** · 06-25-2008

What I simply don't agree with is that cin >> doesn't read whitespace. If it read entire lines, I wouldn't have a problem with it.

O_o

You have the worlds worst logic.

And just for fun... source.

Soma

Code:

#include <iostream>

int main()
{
  char message;
  std::cin >> std::noskipws;
  while(std::cin >> message)
  {
    std::cout << message;
  }
  return(0);
}

**Elysia** · 06-26-2008

Originally Posted by phantomotap

O_o
You have the worlds worst logic.
And just for fun... source.

Soma

o_O
Of course I didn't know of that. That changes a lot of things.
cin >> is now... acceptable. Or I'd maybe say... preferred.
Using operators is better than using stand-alone functions O_O

**MacGyver** · 06-26-2008

If I'm correct, I think the problem here is over the definition of whether the variations of cin's operator>> is appropriate to be labelled as broken.... or "evil", as the case may be.

In terms of C, I suppose cin has the same type of functionality as scanf() more or less. It's good for very simplistic things where you know the exact format of your input, and it's horrible for anything too complex or where the user is not able to properly submit the correct data.

Is that fair enough?

**Elysia** · 06-26-2008

I suppose that is a good look at it.
I still see that it's suitable for reading a line of data for further processing.
But if you need more advanced approach to reading the actual data, then you need to look for other solutions.

What does that mean in a nut shell? I suppose it means I agree.

**laserlight** · 06-26-2008

Of course I didn't know of that. That changes a lot of things.

Heh, you didn't catch my "by default" phrase

Thread: Evil

Thread Tools

Search Thread

Display

Similar Threads

Anyone a Resident Evil fan?

Resident Evil: The Evil Begins-Coder Needed

Evil Fish

evil evil empirical authority....

President Evil