Home/ Questions/Q 929419
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-15T20:10:06+00:00

I have just installed the Windows SDK v7.1 (MSVC 10.0) and running my code

  • 0

I have just installed the Windows SDK v7.1 (MSVC 10.0) and running my code through (almost) full warning level (W3, default for qmake’s CONFIG += warn_on) and am surprised about warning C4800: 'type' : forcing value to bool 'true' or 'false' (performance warning)

In the following code, stream is an std::istream and token is a std::string.

// in some function returning bool
return (stream >> token) // triggers warning c4800:
                         // '(void *)': forcing value to bool 'true' or 'false' (performance warning)`
// somewhere else
if( stream >> token ) // does not trigger warning c4800

What is going on here? I don’t even get why the warning is triggered in the first place. I thought the first bit of code already returned a bool anyways.

I understand this is nitpicking and the warning shouldn’t even exist, but it’s the only one in my code between MSVC’s /W3 and gcc’s -Wall -pedantic, so I’d like to know 🙂

SMALL UPDATE: I understand that the warning is designed to let you know you’re assuming int->bool conversion, but 1) why would you even still use bool (==typedef int mostly) and 2) why would an if(2) not convert 2 to true or false, I thought that was the whole idea of a predicate, being true or false.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    What is going on here? I don’t even get why the warning is triggered in the first place. I thought the first bit of code already returned a bool anyways.

    1. Streams have an implicit conversion operator that returns a void*. (That’s a version of the safe bool idiom. It’s done this way because there is less contexts in which void* compiles than bool, so there’s less contexts in which the implicit conversion could kick in unwanted.)[1]

    2. Streams’ operator>>() returns a reference to its left operand – the stream. That’s so you can chain input operations: strm >> value1 >> value2 is executed as ((strm >> value1) >> value2).

    Now, when you say if( strm >> value ), strm >> value is executed and a stream returned. In order to put that into an if statement, the implicit conversion into void* is performed, and that pointer is then checked for being NULL or not.
    That’s no different from if(ptr), the if statement implicit converts its condition to bool, but compilers would never warn about that, because the condition not being a bool is so common.

    With the return, this is different. If you want to return a certain type, usually the expression you return should be of that type. VC’s warning is quite annoying and for me in 99 out of 100 times it was superfluous. But the remaining 1% (never a performance concern, BTW; I think that is silly about the warning) made me glad the warning is there.

    The workaround for this warning is to 

    return 0 != <expression>

    where <expression> is whatever you think should be considered a boolean value.

    [1] ISTR Stroustrup writing somewhere that an operator bool() would silently compile if you messed up the operators: ostrm >> 5; (note the >> instead of <<) would compile fine, but silently do the wrong thing. (It converts the boolean to an integer and right-shifts that 5 times, then discard the value.)

    • 0