Стоит ли использовать «> =» вместо «==» для большей безопасности при кодировании с другими типами, кроме float?

Question

При работе с плавающей точкой следует использовать

a <= 0.0

вместо

a == 0.0

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

---

Но при использовании других типов переменных, таких как int, может быть полезно сделать то же самое?Как будто у вас есть цикл for, перебирающий переменную int (например, индекс), и когда он достигает числа, он должен что-то делать.Затем следует установить для сравнения значение >= вместо ==, когда оно должно привести к тому же результату?Например, может быть случай, когда == не оценивается в следующем случае:

for (int i = 0; i < 10; i++)
{
    if (i == 5)
    {
        break;
    }
}

И что вместо этого было бы «безопаснее» сделать следующее:

for (int i = 0; i < 10; i++)
{
    if (i >= 5)
    {
        break;
    }
}

Если нет разницы между этими двумя понятиями, когда речь идет о кодировании "безопасно", есть ли разница в производительности или читабельности или что-то еще, что может сделать выбор между способами кодирования?

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

Я слишком параноик, чтобы спрашивать это?

Answer 1

Суть вопроса неверна;слепое использование a <= 0.0 вместо a == 0.0 недопустимо с плавающей запятой.См. Насколько опасно сравнивать значения с плавающей запятой? для рассмотрения темы.

С учетом сказанного, в некоторых случаях использование реляционных операторов неравенства "более жестко", чемиспользование оператора равенства и наоборот .В общем, я бы рекомендовал против этого, так как это может дать вам ложное чувство безопасности ;например, в приведенном в вашем вопросе примере i==5 против i>=5 компилятор, вероятно, сможет доказать, что они одинаковы, и при необходимости оптимизировать их для другого.Это означает, что он не обязательно сделает что-либо, чтобы защитить вас от переполнения стека, нейтрино или любой другой причины, из-за которой значение i может стать чем-то отличным от 0..5 вне определенной семантики языка.

Есть также некоторые случаи, когда использование равенства определяется неравенством, особенно с указателями.Если pos и end оба указатели, pos==end четко определен, если они оба действительны.Но если они оба равны NULL, а pos==end четко определен и истинен, pos>=end - неопределенное поведение.Аналогично, если они оба указывают на разные массивы (в частности, если end указывает на дозорного, не являющегося частью вашего массива), pos==end всегда будет ложным, но pos>=end - неопределенное поведение.

Я такжевводить в заблуждение запись if (i>=5), если вы знаете, что логически невозможно i>5, - это заставляет читателя задуматься о том, возможно ли это, а если нет, то почему вы написали это так вместо if (i==5).

Answer 2

Как и в любом случае, когда == не оценивается

Нет, использование == безопасно.Целые числа представляют все значения в пределах диапазона целочисленного типа, используемого точно.Сюрпризов нет.

Если затем установить для сравнения значение> = вместо ==

Поскольку результат один и тот же, вы можете сделать оба, но янашел бы >= запутанным.Так что для удобочитаемости я предпочитаю ==

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

Вы не можете сказать, взглянув на код C.Это зависит от используемой системы (ЦП).В целом, однако, я бы сомневался, что вы почувствуете какую-то существенную разницу.

Answer 3

Ответ, это зависит.Если у вас есть такой цикл:

for (int i = 0; i < 10; i++)
{
    if (i == 5)
    {
        break;
    }
}

Тогда нет никакой опасности в i пропуске 5.

С другой стороны, если у вас есть что-то вроде этого:

volatile int i;

void interrupt(void)
{
    i++;
}

void foo(void)
{
    for (i = 0; i < 10; i++)
    {
        if (i == 5)
        {
            break;
        }
    }
}

Тогда i может измениться вне нормального потока программы (например, из-за прерывания).В этом случае >= будет разумным.