Evil

This is a discussion on Evil within the C++ Programming forums, part of the General Programming Boards category; Use std::getline instead of cin >> as well. The latter is evil (won't read spaces)....

  1. #1
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,413

    Evil

    Use std::getline instead of cin >> as well. The latter is evil (won't read spaces).
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  2. #2
    Registered User
    Join Date
    Jan 2005
    Posts
    7,317
    >> 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 >>.

  3. #3
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,413
    If you say so, but I'd still call it evil. The point as to why it's evil was made anyway.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  4. #4
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    21,313
    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.
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  5. #5
    Registered User
    Join Date
    Jan 2005
    Posts
    7,317
    >> 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.

  6. #6
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,413
    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.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  7. #7
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    21,313
    Then what is the official definition of evil?
    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
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  8. #8
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,413
    Quote Originally Posted by laserlight View Post
    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™.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  9. #9
    Registered User
    Join Date
    Jan 2005
    Posts
    7,317
    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.

  10. #10
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,413
    Quote Originally Posted by Daved View Post
    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.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  11. #11
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    21,313
    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.
    In other words, you do not see formatted input as a good thing.
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  12. #12
    Registered User
    Join Date
    Jan 2005
    Posts
    7,317
    >> 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.

  13. #13
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,413
    Quote Originally Posted by laserlight View Post
    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.

    Quote Originally Posted by Daved View Post
    >> 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?
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  14. #14
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    21,313
    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.
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  15. #15
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,413
    Why not just split the discussion?
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

Page 1 of 2 12 LastLast
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Anyone a Resident Evil fan?
    By SlyMaelstrom in forum A Brief History of Cprogramming.com
    Replies: 4
    Last Post: 12-02-2005, 07:21 PM
  2. Resident Evil: The Evil Begins-Coder Needed
    By ^Tomala^ in forum Projects and Job Recruitment
    Replies: 8
    Last Post: 01-04-2005, 04:37 PM
  3. Evil Fish
    By RoD in forum A Brief History of Cprogramming.com
    Replies: 29
    Last Post: 07-10-2003, 10:27 AM
  4. evil evil empirical authority....
    By DavidP in forum A Brief History of Cprogramming.com
    Replies: 9
    Last Post: 03-25-2003, 03:33 PM
  5. President Evil
    By GanglyLamb in forum A Brief History of Cprogramming.com
    Replies: 24
    Last Post: 01-29-2003, 06:54 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21