Thread: evaluation of (std::cin >> var) explanation needed.

  1. #1
    Registered User
    Join Date
    Jan 2009
    Posts
    1,485

    evaluation of (std::cin >> var) explanation needed.

    Hey, I'm picking up C++. I have a question about the evaluation of the following:

    Code:
    int var;
    
    if(std::cin >> var)
          //do something
    It's my understanding that this evaluates to true as long as the input is not end-of-file or a non int. But what is it that is returned exactly? Tried this:

    Code:
            while( (void *ret = (std::cin >> var)) ){
                    printf("%d, %p, %d\n", var, ret, *((int*)(ret)));
            }
    I have found out that it's a void* but, it's not an object (hence the cast), well what is it then?
    Last edited by Subsonics; 09-04-2010 at 01:36 PM.

  2. #2
    Algorithm Dissector iMalc's Avatar
    Join Date
    Dec 2005
    Location
    New Zealand
    Posts
    6,318
    It's probably the safe-bool idiom, which means it will be either 0 or an arbitrary function address, the actual value being of no consequence whatsoever.
    All we're supposed to care about is that it's implicitly convertible to a bool (true/false).
    My homepage
    Advice: Take only as directed - If symptoms persist, please see your debugger

    Linus Torvalds: "But it clearly is the only right way. The fact that everybody else does it some other way only means that they are wrong"

  3. #3
    Lurking whiteflags's Avatar
    Join Date
    Apr 2006
    Location
    United States
    Posts
    9,613
    if (std::cin >> something)

    Two things happen in that statement. First, operator >> does its work and returns a reference to the object. Doing this allows programmers to combine method calls, in this way:

    std::cin.operator>>(std::cin, something).operator>>(std::cin, otherThing);

    That looks weird, probably, but that's the idea in general. It's only because operators are used that it looks like this:

    std::cin >> something >> otherThing;

    Secondly, the std::cin object turns to a bool type in Boolean contexts, where you are evaluating the truth of a statement. Actually, std::cin converts to void* first and then the pointer is tested for 0. So, when the stream is bad but needs to be evaluated as a bool it turns into a null pointer.

    So that's the full explanation.

    I would just like to note something about chaining stream operations -- extracting stuff in particular -- here. If you chain operations and there is a stream error in the middle of the chain, the stream will go into a bad state, but it will be difficult to know exactly where the error occurred. It could have been any part of the chain.

  4. #4
    Registered User
    Join Date
    Jan 2009
    Posts
    1,485
    Thanks for the explanation. I guess for practical purposes the only thing that should matter is that it works, but I always get curious about what's going on in the background when given abstractions. I've been doing C for a while now and it seems a bit more transparent in this regard, again thanks.

  5. #5
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    28,413
    It is interesting that you are not so curious as to why the conversion is to void* rather than directly to bool

    iMalc mentioned the safe bool idiom, but this technique is not the safe bool idiom. However, this article on the safe bool idiom explains this technique as well: The Safe Bool Idiom. In the next version of C++, it is expected that we will have explicit conversion functions, thus eliminating the need for the safe bool idiom (and this convert to void* technique).
    Quote Originally Posted by Bjarne Stroustrup (2000-10-14)
    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.
    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  6. #6
    Registered User
    Join Date
    Jan 2009
    Posts
    1,485
    Quote Originally Posted by laserlight View Post
    It is interesting that you are not so curious as to why the conversion is to void* rather than directly to bool
    If you know, by all means, spill the beans.

    Quote Originally Posted by laserlight View Post
    iMalc mentioned the safe bool idiom, but this technique is not the safe bool idiom. However, this article on the safe bool idiom explains this technique as well: The Safe Bool Idiom. In the next version of C++, it is expected that we will have explicit conversion functions, thus eliminating the need for the safe bool idiom (and this convert to void* technique).
    Thanks for the link laserlight

  7. #7
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    Quote Originally Posted by Subsonics View Post
    If you know, by all means, spill the beans.
    I think the article discusses that, and the danger of implicit conversion operators.
    Hence a workaround has been devised to do boolean testable without the side effects.
    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.

  8. #8
    Registered User
    Join Date
    Jan 2009
    Posts
    1,485
    Quote Originally Posted by Elysia View Post
    I think the article discusses that, and the danger of implicit conversion operators.
    Hence a workaround has been devised to do boolean testable without the side effects.
    Yes, having read it now, I realize I drew the wrong conclusion from the name of the link. I think I will come back to it again later, some of that was beyond what I have learned about C++ so far.

  9. #9
    Lurking whiteflags's Avatar
    Join Date
    Apr 2006
    Location
    United States
    Posts
    9,613
    Quote Originally Posted by laserlight View Post
    this article on the safe bool idiom explains this technique as well: The Safe Bool Idiom. In the next version of C++, it is expected that we will have explicit conversion functions, thus eliminating the need for the safe bool idiom (and this convert to void* technique).
    Will streams be used differently or different at all because of this change in the standard?

  10. #10
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    I doubt that they will change except that perhaps they will use an explicit bool operator instead of conversion to void*. But that remains to be seen.
    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
    28,413
    Quote Originally Posted by whiteflags
    Will streams be used differently or different at all because of this change in the standard?
    If you have been misusing the conversion to void*, you will find that your code will no longer compile
    Quote Originally Posted by Bjarne Stroustrup (2000-10-14)
    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.
    Look up a C++ Reference and learn How To Ask Questions The Smart Way

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Replies: 3
    Last Post: 08-16-2010, 10:00 AM
  2. Need help assignment
    By 6kaine9 in forum C Programming
    Replies: 26
    Last Post: 10-19-2008, 08:51 PM
  3. server question
    By xddxogm3 in forum Tech Board
    Replies: 24
    Last Post: 01-21-2004, 01:12 AM
  4. Vigenere Decipher/Encipher
    By Xander in forum C++ Programming
    Replies: 5
    Last Post: 02-15-2002, 09:24 AM