C++ полагается на неявное преобразование в bool в условиях?

В большинстве случаев это не ужасно, но может быть более читабельным, если вы напечатаете именно то, что имеете в виду.

Это правило связывает вас, если вы когда-нибудь захотите использовать класс с неявным преобразованием в bool , например std :: istream . Этот код считывает слово за раз из файла до тех пор, пока не будет достигнут EOF:

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

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

Оператор извлечения потока возвращает ссылку на файловый поток, который неявно преобразуется в bool , чтобы указать, находится ли поток еще в хорошем состоянии. Когда вы дойдете до конца файла, тест не пройдет. Ваш стандарт кодирования не позволяет вам использовать эту общую конструкцию.

Для типов указателей это не имеет большого значения. Компилятор, вероятно, создаст примерно такой же код для неявного преобразования в bool и явного теста на NULL . Тут дело вкуса - ни один из них не "лучше". в абсолютном смысле. Стандарт кодирования просто пытается обеспечить согласованный стиль.

Имея это в виду, вы должны полностью следовать стандарту кодирования при работе со встроенными типами (указатели, целые числа и т. Д.). Если вы столкнетесь с ситуацией, аналогичной описанной выше, с классом, имеющим законное преобразование в bool , я подниму этот вопрос перед вашими товарищами по команде.

Иногда мне кажется, что это правило может быть нарушено, например, при работе со стандартными библиотеками, которые возвращают int вместо bool (для совместимости с C89).

Однако это правило обычно приводит к упрощению понимания кода. Это правило применяется даже в таких языках, как C #, и там не слишком много жалоб на него, поэтому нет серьезных недостатков в следовании этому правилу, кроме необходимости к нему привыкать.

Это никак не повлияет на скомпилированный код.

Что касается его полезности is - это, безусловно, поможет понять людям, пришедшим с таких языков, как Java / C #. Это сделает более ясным то, что вы проверяете. Это' выдает предупреждение, если вы начинаете сравнивать целые числа с NULL (и тем самым указывать, что вы не уверены в типе рассматриваемой переменной). Я лично предпочитаю первую форму, но это не совсем необоснованное требование.

Правило, которое не добавляет никакой выгоды, - это правило, которое вы можете с пользой удалить.

Мне это правило очень не нравится. В C ++ идиоматично использовать неявное преобразование в bool для типов указателей (и, конечно, для логических типов). ИМО, читать

bool conditionMet = false;

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

намного легче, чем читать это:

bool conditionMet = false;

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

То же самое и с указателями. Кроме того, вводя ненужное сравнение, вы предоставляете еще одну возможность опечататься и в итоге получить назначение вместо сравнения, что, конечно, приведет к нежелательным результатам. В случаях, когда вы используете целые числа как логические значения, как в старом коде на C, я думаю, вам также следует использовать неявное преобразование в логическое значение.

Это впечатляюще глупое правило.

if (ptr != NULL) // ok

тогда почему бы не

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