Всегда ли полезно деление на ноль, сопровождаемое ошибкой времени выполнения, в C++?

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

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

Деление на 0 — это поведение undefined, поскольку на некоторых платформах оно может вызвать аппаратное исключение. Мы все могли бы желать лучшего поведения оборудования, но поскольку никто никогда не считал нужным иметь целые числа со значениями -INF/+INF и NaN, это совершенно бессмысленно.

Теперь, поскольку это поведение undefined, могут происходить интересные вещи. Я рекомендую вам прочитать статьи Криса Латтнера о неопределенном поведении и оптимизации, я просто приведу здесь небольшой пример:

int foo(char* buf, int i) {
  if (5 / i == 3) {
    return 1;
  }

  if (buf != buf + i) {
    return 2;
  }

  return 0;
}

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

Перед лицом таких преобразований любой, кто надеется на разумное поведение деления на 0..., будет жестоко разочарован.

В случае целочисленных типов (int, short, long и т. д.) я не могу придумать никаких применений для преднамеренного деления на ноль навскидку.

Однако для типов с плавающей запятой на оборудовании, совместимом с IEEE, явное деление на ноль чрезвычайно полезно. Вы можете использовать его для получения положительных и отрицательных значений бесконечности (+/- 1/0), а не числовых значений (NaN, 0/0), что может быть весьма полезным.

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

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

Хотя вы можете получить доступ к этим значениям с помощью макросов и std::numeric_limits (в C++), полезно иметь возможность создавать их самостоятельно (и позволяет избежать большого количества кода "особого случая"). Это также позволяет разработчикам стандартной библиотеки не прибегать к хакерским действиям (таким как ручная сборка правильной последовательности битов FP) для предоставления этих значений.

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

Обнаружение деления на ноль во время компиляции — это то, что вы хотели бы иметь в качестве предупреждения компилятора. Это определенно хорошая идея.

Я не дружу с Microsoft Visual C++, но G++ 4.2.1 делает такую ​​проверку. Попробуйте скомпилировать:

#include <iostream>

int main() {
    int x = 1;
    int y = x / 0;
    std::cout << y;
    return 0;
}

И оно скажет вам:

test.cpp: In function ‘int main()’:
test.cpp:5: warning: division by zero in ‘x / 0’

Но считать это ошибкой — это скользкий путь, на который сообразительные не тратят слишком много свободного времени, лазая по нему. Подумайте, почему G++ нечего сказать, когда я пишу:

int main() {
    while (true) {
    }
    return 0;
}

Как вы думаете, он должен скомпилировать это или выдать ошибку? Должен ли он всегда выдавать предупреждение? Если вы считаете, что он должен вмешиваться во всех таких случаях, я с нетерпением жду вашей копии написанного вами компилятора, который компилирует только программы, гарантирующие успешное завершение! :-)