C++ rely on implicit conversion to bool in conditions?

Question

I found the following rule in a coding standards sheet :

Do not rely on implicit conversion to bool in conditions.

if (ptr) // wrong

if (ptr != NULL) // ok

How reasonable/usefull is this rule?

How much overload on the compiled code?

Answer 1

This won't affect the compiled code at all.

As for how useful it is - it'll certainly aid comprehension for people coming from languages such as Java/C#. It'll make it more explicit what you're checking for. It'll throw a warning if you start comparing ints to NULL (and thereby indicate that you're hazy about the type of the variable in question). I personally prefer the first form, but it's not a totally unreasonable requirement.

Answer 2

In most cases, it's not horrible, but it can be more readable if you type exactly what you mean.

Answer 3

Sometimes I think this rule can be broken, when e.g. dealing with standard libraries which return int instead of bool (for compatibility with C89).

However, this rule generally leads to easier-to-understand code. It's even enforced in languages like C# and it's not complained about too much there, so there are no major downsides to following this rule other than having to get used to it.

Answer 4

A rule that adds zero benefit is a rule you can profitably delete.

Answer 5

In the strictest sense, you can rely on implicit conversions to bool. Backwards compatibility with C demands it.

Thus it becomes a question of code readability. Often the purpose of code standards is to enforce a sameness to the code style, whether you agree with the style or not. If you're looking at someone else's standard and wondering if you should incorporate it into your own, go ahead and debate it - but if it's your company's long-standing rule, learn to live with it.

Answer 6

I dislike this rule very much. It is idiomatic in C++ to use the implicit conversion to bool for pointer types (and of course for boolean types). IMO, it is much easier to read

bool conditionMet = false;

while (!conditionMet) // read as "while condition is not met"
{
    /* do something */
}

than it is to read this:

bool conditionMet = false;

while (conditionMet == false) // read as "while conditionMet is false"
{
    /* do something */
}

It's the same for pointers. Also, by introducing the unnecessary comparison, you're introducing yet another opportunity to mistype and end up with an assignment instead of a comparison, which of course will produce undesired results. In cases where you're using ints as bools, as with old C code, I think you should also use the implicit conversion to bool.

Answer 7

That rule puts you in a bind if you ever want to use a class that has an implicit conversion to bool, such as std::istream. This code reads a word at a time from a file until EOF is reached:

std::ifstream file("foo.txt");
std::string word;

while (file >> word)
{
    // do stuff
}

The stream extraction operator returns a reference to the file stream, which is implicitly converted to bool to indicate whether the stream is still in a good state. When you reach the end of the file, the test fails. Your coding standard precludes you from using this common construct.

For pointer types, it's not a big deal. The compiler will probably produce about the same code for the implicit conversion to bool and the explicit test against NULL. It's a matter of taste at that point - neither one is "better" in an absolute sense. The coding standard is simply trying to enforce a consistent style.

With that in mind, you should absolutely follow the coding standard when dealing with built-in types (pointers, ints, etc.). If you run into a similar situation to the above with a class having a legitimate conversion to bool, I would raise the issue with your teammates.

Answer 8

That's an impressively stupid rule.

if (ptr != NULL) // ok

then why not

 if ((ptr != NULL)==true)