Use std::getline instead of cin >> as well. The latter is evil (won't read spaces).
>> Use std::getline instead of cin >> as well. The latter is evil (won't read spaces).
That doesn't make it evil. It works fine for many applications and is often the better choice. There is a commonly accepted definition of "evil" that doesn't apply to cin >>.
std::getline is evil as it reads spaces
I think it is better to say that formatted input with the overloaded operator>> may not be appropriate in this case since a filename and the content may contain whitespace.
Look up a C++ Reference and learn How To Ask Questions The Smart WayOriginally Posted by Bjarne Stroustrup (2000-10-14)
>> 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.Then what is the official definition of 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 evilTo me, it's a function that does not do what you expect it to do. Therefore, it is evil.
Look up a C++ Reference and learn How To Ask Questions The Smart WayOriginally Posted by Bjarne Stroustrup (2000-10-14)
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.
And here's another one...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
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™.
The catb definition seems to be appropriate, as does this one from C++ FAQ Lite: http://www.parashift.com/c++-faq-lit....html#faq-6.15
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?
Last edited by Daved; 06-25-2008 at 11:55 AM.
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.
I'll have to agree.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.
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.
Indeed I do.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?
You should avoid it and use better functions, such as split and regular expressions IMO.
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.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 >>.
I do not see this as a problem. In any case, you must always check for a failed read.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.
In other words, you do not see formatted input as a good thing.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.
Look up a C++ Reference and learn How To Ask Questions The Smart WayOriginally Posted by Bjarne Stroustrup (2000-10-14)
>> 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.
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.
Except it's less of a hassle to just check if a conversion failed rather than checking and clearing the input buffer.I do not see this as a problem. In any case, you must always check for a failed read.
Well, I do believe that you first fetch all the data from the user and then interpret it and format it.In other words, you do not see formatted input as a good thing.
Not using cin >> to do that.
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.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?
Look up a C++ Reference and learn How To Ask Questions The Smart WayOriginally Posted by Bjarne Stroustrup (2000-10-14)