Why does std::basic_ios overload the unary logical negation operator?

Question

The C++ IO streams' base class std::basic_ios defines operator void*() to return !fail() and operator!() to return fail(). That makes me wonder why we need the operator!() at all. Certainly, !is would also work by implicitly calling operator void*() and negating its result.

Am I missing something here or is it purely for historical reasons that std::basic_ios::operator!() is defined?

A question on comp.lang.c++.moderated didn't bring any answers either.

Answer 1

With old (read: not long after cfront) C++ compilers, the compiler was not guaranteed to implicitly call typecast operators on objects when needed. If iostream didn't have an operator ! declared, then you couldn't expect !cout to work in all cases. C++89 (or whatever the pre-C++98 standard was called) simply left the area undefined.

This is also why operator void*() was overloaded, and not operator int or operator bool. (bool didn't even exist as its own type in the standard at that point.) I remember my professor telling me that if(), under the hood, expected a void* in C++, because that type could act as a "superset" type relative to those expression result types that would be passed to an if statement, but I have not found this spelled out anywhere.

This was around the time of gcc 2, when most folks didn't support templates or exceptions, or if they did, didn't fully support them, so metaprogramming C++ with templates was still a theoretical exercise and you made sure to check that operator new didn't return a null pointer.

This drove me nuts for several years.

An interesting excerpt from Stroustrup's The C++ Programming Language, 3rd ed. (1997), page 276:

The istream and ostream types rely on a conversion function to enable statements such as

while (cin >> x) cout << x;

The input operation cin>>x returns an istream&. That value is implicitly converted to a value indicating the state of cin. The value can then be tested by while. However, it is typically not a good idea to define an implicit conversion from one type to another in such a way that information is lost in the conversion.

There's a lot in C++ that seems to be a victory of cute or clever over consistent. I wouldn't mind one bit if C++ was smart enough to handle the above loop as:

while (!(cin >> x).fail()) cout << x;

because this, while more verbose and more punctuation, is clearer to a beginning programmer.

... Actually, come to think of it, I don't like either of those constructs. Spell it out:

for(;;)
{   cin >> x;
    if(!cin)
        break;
    cout << x;
}

Why do I like this better? Because this version makes it far clearer how to expandthe code to, say, handle two reads at a time instead of one. For example, "The existing code copies a sequence of float values. We want you to change it so it pairs up the float values and writes them out, two per line, because we're now using complex numbers."

But I digress.

Answer 2

Ok, coming up dry here, I went and asked on comp.lang.c++.moderated.

At first, the results were just as bad as they've been here, but in the end Daniel Krügler's answer concurred in my suspicion that there are no technical reasons for operator!():

I have been told, that this additional declaration was added to emphasize the symmetry between the "true" case and it's negation, just as a guide for the reader, nothing more. To be fair, the idiom

operator void*

was rather new at this time and given this the deduction which syntax support is provided by this feature is not immediately obvious. Other than that there was no further technical reason to do so. [...]

Answer 3

Looking at the implementation of MinGW, which is shipped with Codeblocks shows me this code:

  operator void*() const
  { return this->fail() ? 0 : const_cast<basic_ios*>(this); }

  bool
  operator!() const
  { return this->fail(); }

It seems to me, that the operator void*() const is intended for more uses than only for the check of success. On top of that it serves also as a casting operator (we're returning this). Right now I am scratching my head a little bit, why we may want to cast this to void*. But the rest is quite clear - if you've got an erroneous stream anyway, you can also return null.