Присваивание в «если» условие

Question

Недавно я только что потерял какое-то время, выясняя ошибка в моем коде, который был вызван опечатка:

if(a=b) 

вместо:

if(a==b) 

Я задавался вопросом если есть какой-либо конкретный случай, вы хотели бы присвоить значение переменной в операторе if, или если нет, то почему компилятор не выдает предупреждение или ошибку?

Answer 1

if (Derived* derived = dynamic_cast<Derived*>(base)) { 
    // do stuff with `derived` 
} 

Хотя это часто упоминаются как анти-паттерн («использовать виртуальную отправку!»), Иногда Derived типа имеет функциональные возможности, что Base просто не (и, следовательно, различные функции), и это является хороший способ включить эту семантическую разницу.

Answer 2

Оператор присваивания возвращает значение присвоенное значение. Таким образом, я мог бы использовать его в подобной ситуации:

if(x = getMyNumber())

Тогда я задаю x быть значение, возвращенное и проверить, если это не ноль.

Избегайте этого, я привел вам пример, чтобы помочь вам понять это.

Редактировать: Добавление Просто предложение (может показаться).

К избежать таких ошибок вверх некоторые проходит один должно написать, если условие, как if(NULL == ptr) вместо if(ptr == NULL) Потому что когда вы орфографических ошибок проверки равенства оператора == как оператор =, компиляция будет бросать Lvalue ошибку с if(NULL = ptr), но if(res = NULL) переданный компилятором (что не то, что вы имеете в виду) и остается ошибкой в ​​коде для времени выполнения.
По той же причине я предпочитаю писать if(getMyNumber() ==x) вместо if(x == getMyNumber())

следует также прочитать: Criticism относительно такого кода.

Answer 3

Выполнение задания в if является довольно распространенным явлением, хотя также часто случается, что люди делают это случайно.

Обычная картина:

if (int x = expensive_function_call()) 
{ 
    // ...do things with x 
} 

Анти-шаблон, где вы ошибочно приписывая вещи:

if (x = 1) 
{ 
    // Always true 
} 
else 
{ 
    // Never happens 
} 

Вы можете избежать этого, до некоторой степени, разместив константы или const , поэтому ваш компилятор выдаст ошибку:

if (1 = x) 
{ 
    // Compiler error, can't assign to 1 
} 

= vs. == - это то, что вам нужно для развития глаз. Я обычно помещаю пробел вокруг оператора, поэтому более очевидно, какая операция выполняется, так как longname=longername очень похож на longname==longername, но = и == сами по себе, очевидно, разные.

Answer 4

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

Answer 5

why doesn't the compiler throw a warning

Некоторые компиляторы будут генерировать предупреждения о подозрительных присвоений в условном выражении, хотя вы обычно должны включить предупреждение в явном виде.

Например, в Visual C++ вы должны включить C4706 (или предупреждения уровня 4 в целом). Обычно я включаю столько предупреждений, сколько могу, и делаю код более явным, чтобы избежать ложных срабатываний. Например, если бы я действительно хотел сделать это:

if (x = Foo()) { ... } 

Тогда я бы написать:

if ((x = Foo()) != 0) { ... } 

Компилятор видит явное испытание и предполагает, что назначение было сделано намеренно, так что вы не Здесь нет ложного положительного предупреждения.

Единственным недостатком такого подхода является то, что вы не можете использовать его, когда переменная объявлена ​​в условии. То есть, вы не можете переписать:

if (int x = Foo()) { ... } 

в

if ((int x = Foo()) != 0) { ... } 

Синтаксически, что не работает. Таким образом, вы либо должны отключить предупреждение, либо поставить компромисс в отношении того, насколько сильно вы занимаетесь областью x.

Answer 6

Ниже приведена некоторая история этого синтаксиса.

В классическом C, обработка ошибок часто делается, написав что-то вроде:

int error; 
... 
if(error = foo()) { 
    printf("An error occured: %s\nBailing out.\n", strerror(error)); 
    abort(); 
} 

Или, когда там было вызов функции, которая может возвращать пустой указатель, идиома была использована наоборот:

Bar* myBar; 
... //in old C variables had to be declared at the start of the scope 
if(myBar = getBar()) { 
    //do something with myBar 
} 

Однако этот синтаксис опасно близко к

if(myValue == bar()) ... 

, поэтому многие люди рассматривают назначение в состоянии плохого стиля, и компиляторы начали предупреждать об этом (по крайней мере, с -Wall).Тем не менее, это предупреждение можно избежать, добавив дополнительный набор скобок:

if((myBar = getBar())) { //tells the compiler: Yes, I really want to do that assignment! 

Тогда C99 пришли вокруг, что позволяет смешивать определения и утверждения, поэтому многие разработчики часто пишут что-то вроде

Bar* myBar = getBar(); 
if(myBar) { 

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

if(Bar* myBar = getBar()) { 

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

if(Bar* myBar = getBar()) { 
    ... 
} 
foo(myBar->baz); //compiler error 
//or, for the C++ enthusiasts: 
myBar->foo();  //compiler error 

Без определения переменной внутри if заявления, это условие не будет обнаружено.

Чтобы сделать длинный ответ коротким: Синтаксис в вашем вопросе является продуктом простоты и силы старого C, но он злой, поэтому компиляторы могут предупредить об этом. Поскольку это также очень полезный способ выразить общую проблему, теперь существует очень краткий, надежный способ добиться такого же поведения. И для этого есть много хороших, возможных применений.

Answer 7

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

Предположим, вы хотите проверить несколько условий в одном, если, и если какое-либо из условий истинно, вы хотите сгенерировать сообщение об ошибке. Если вы хотите включить в сообщение об ошибке, которое определенное условие вызвало ошибку, вы можете сделать следующее:

std::string e; 
if(myMap[e = "ab"].isNotValid() || 
    myMap[e = "cd"].isNotValid() || 
    myMap[e = "ef"].isNotValid()) 
{ 
    // here, e has the key for which the validation failed 
} 

Так что, если второе условие является одним, что истинно, е будет равна «кд» , Это связано с поведением короткого замыкания ||, которое предусмотрено стандартом (если только не перегружено). См. this ответ для получения более подробной информации о коротком замыкании.