I get maybe two dozen requests for help with some sort of programming or design problem every day. Most have more sense than to send me hundreds of lines of code. If they do, I ask them to find the smallest example that exhibits the problem and send me that. Mostly, they then find the error themselves. "Finding the smallest program that demonstrates the error" is a powerful debugging tool.

>> If you say so, but I'd still call it evil. The point as to why it's evil was made anyway.
Then you'd be wrong. You're using neither the official definition of evil, nor the commonly accepted usage of the term as it applies to programming constructs.

We could use Eric Raymond's definition of evil, though I think that common usage with respect to C and C++ comes closer to his definition of cretinous.

To me, it's a function that does not do what you expect it to do. Therefore, it is evil.

I expect the overloaded operator>> for ostream to skip whitespace by default, therefore it is not evil. Actually, I also expect gets() to result in a buffer overrun under some circumstances, therefore gets() is not evil

I get maybe two dozen requests for help with some sort of programming or design problem every day. Most have more sense than to send me hundreds of lines of code. If they do, I ask them to find the smallest example that exhibits the problem and send me that. Mostly, they then find the error themselves. "Finding the smallest program that demonstrates the error" is a powerful debugging tool.

We could use Eric Raymond's definition of evil, though I think that common usage with respect to C and C++ comes closer to his definition of cretinous.

If we take a look at the first link, it says that it's evil if its purpose is not aligned with what is expected from the speaker. Thus, if I expect cin >> to read everything that I enter, including whitespace, then it is evil, because it does not.
On the other hand, it does not meet the criteria for the other evil, which says it must be poorly designed. Although it does not specify from the perspective of whom. People will always have different opinions, so there's another argument right there.
Although, in my view, cin >> is also maldesigned, so it is evil in my view.

I expect the overloaded operator>> for ostream to skip whitespace by default, therefore it is not evil. Actually, I also expect gets() to result in a buffer overrun under some circumstances, therefore gets() is not evil

And here's another one...
gets clearly fits the second definition of evil very well, but may or may not fit the first definition of evil depending on the speaker. In my view, it matches the first one very well, so it is indeed, evil™.

Both definitions state that something has enough problems that it should rarely or never be used. That does not apply to cin >>, since that construct can and should be used often.

And of course any "speaker" can have bizarre expectations, but that doesn't mean that their assertion that something is evil is correct in general, it means that it is correct only based on their misguided expectations.

The point is that claiming cin >> is evil implies that it should not be used in most cases. That implication is incorrect, since there are many valid uses for it. Do you disagree with that?

Both definitions state that something has enough problems that it should rarely or never be used. That does not apply to cin >>, since that construct can and should be used often.

I don't think I agree.
cin >> for extracting things from a stream can easily be replaced by std::getline and a split function (something that's even available in boost with regular expressions), which is far more powerful and gives more options than cin >>.
Reading other things, such as integral data with cin >> is even worse because it can "block" the input buffer if poor data is entered, leaving the programmer to check for poor data and clean up the buffer to make it work again.
So in essence, I do not see cin >> as a good thing. It is maldesigned and does not perform as it should. Thus it is evil.
Again, however, as the FAQ clearly states, being evil does not always mean it shouldn't be used. It's perfectly well for newbies before they learn better ways.

And of course any "speaker" can have bizarre expectations, but that doesn't mean that their assertion that something is evil is correct in general, it means that it is correct only based on their misguided expectations.

I'll have to agree.
But it still leaves the question as to which individual's opinion or which group's opinion should be considered valid.
There are many expert programmers, but not everyone may have the same opinions.

The point is that claiming cin >> is evil implies that it should not be used in most cases. That implication is incorrect, since there are many valid uses for it. Do you disagree with that?

Indeed I do.
You should avoid it and use better functions, such as split and regular expressions IMO.

cin >> for extracting things from a stream can easily be replaced by std::getline and a split function (something that's even available in boost with regular expressions), which is far more powerful and gives more options than cin >>.

The problem with that is that you have forgotten that operator>> is overloaded on a per-object basis. Using std::getline and a split function is less powerful than using an overloaded operator>> designed to read input for a user defined object. Of course, it is as powerful as a read function overloaded for that object, but the concept here is formatted input, whereas a read function does not necessarily have that connotation.

Reading other things, such as integral data with cin >> is even worse because it can "block" the input buffer if poor data is entered, leaving the programmer to check for poor data and clean up the buffer to make it work again.

I do not see this as a problem. In any case, you must always check for a failed read.

So in essence, I do not see cin >> as a good thing. It is maldesigned and does not perform as it should. Thus it is evil.

I get maybe two dozen requests for help with some sort of programming or design problem every day. Most have more sense than to send me hundreds of lines of code. If they do, I ask them to find the smallest example that exhibits the problem and send me that. Mostly, they then find the error themselves. "Finding the smallest program that demonstrates the error" is a powerful debugging tool.

>> being evil does not always mean it shouldn't be used. It's perfectly well for newbies before they learn better ways.

I guess this highlights where we disagree. Evil implies newbies should not learn it because they would be performing bad habits. The term "evil" is often used specifically for newbies since more complex explanations would not be understood without proper background. In this case, it is unnecessary to discourage newbies from using cin >>, so calling it evil is detrimental.

>> But it still leaves the question as to which individual's opinion or which group's opinion should be considered valid.

You appear to have a similar definition of evil as I do, you just applied it in a way that I disagree with here.

The problem with that is that you have forgotten that operator>> is overloaded on a per-object basis. Using std::getline and a split function is less powerful than using an overloaded operator>> designed to read input for a user defined object. Of course, it is as powerful as a read function overloaded for that object, but the concept here is formatted input, whereas a read function does not necessarily have that connotation.

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.

I do not see this as a problem. In any case, you must always check for a failed read.

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

In other words, you do not see formatted input as a good thing.

Well, I do believe that you first fetch all the data from the user and then interpret it and format it.
Not using cin >> to do that.

Originally Posted by Daved

>> being evil does not always mean it shouldn't be used. It's perfectly well for newbies before they learn better ways.
I guess this highlights where we disagree. Evil implies newbies should not learn it because they would be performing bad habits. The term "evil" is often used specifically for newbies since more complex explanations would not be understood without proper background. In this case, it is unnecessary to discourage newbies from using cin >>, so calling it evil is detrimental.

But this also brings up another question I thought of:
Should C++ have elements that are simply good for newbies for their first program, such as cin >> integer?
If it should be considered bad to use it altogether and use the correct approach from the beginning, it could be called evil.
Otherwise, might we just spell it differently? Discouraged, perhaps?

But this also brings up another question I thought of:
Should C++ have elements that are simply good for newbies for their first program, such as cin >> integer?
If it should be considered bad to use it altogether and use the correct approach from the beginning, it could be called evil.
Otherwise, might we just spell it differently? Discouraged, perhaps?

Kindly start a new thread for your proposed discussion as this thread has to do with bobbelPoP's questions.

I get maybe two dozen requests for help with some sort of programming or design problem every day. Most have more sense than to send me hundreds of lines of code. If they do, I ask them to find the smallest example that exhibits the problem and send me that. Mostly, they then find the error themselves. "Finding the smallest program that demonstrates the error" is a powerful debugging tool.