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

Question

я нашел следующее правило в coding standards sheet:

Не следует полагаться на неявное преобразование к BOOL в условиях.

если (PTR) // неправильно

если (PTR! = NULL) // нормально

Как разумно/полезно есть это правило?

Сколько стоит перегрузка скомпилированного кода?

Answer 1

В строгом смысле, вы можете полагаться на неявные преобразования в bool. Обратная совместимость с C требует этого.

Таким образом, это становится вопросом читаемости кода. Часто цель стандартов кода заключается в обеспечении единообразия стиля кода, независимо от того, согласны ли вы со стилем или нет. Если вы смотрите на чужой стандарт и задаетесь вопросом, следует ли включить его в свой собственный, обсудите его, но если это давнее правило вашей компании, научитесь жить с ним.

Answer 2

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

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

Answer 3

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

Answer 4

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

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

Answer 5

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

Answer 6

Мне не нравится это правило. В 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 */ 
} 

Это же для указателей. Кроме того, вводя ненужное сравнение, вы вводите еще одну возможность ошибиться и получить назначение вместо сравнения, что, конечно же, приведет к нежелательным результатам. В тех случаях, когда вы используете int как bools, как и со старым C-кодом, я думаю, вы также должны использовать неявное преобразование в bool.

Answer 7

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

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

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

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

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

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

Answer 8

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

if (ptr != NULL) // ok 

, то почему бы не

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