Здравствуйте, netch80, Вы писали:

N>Здравствуйте, cppguard, Вы писали:

На все вопросы ответ один: NaN в райнтайме это очень-очень плохо, и если он появился, то в коде кто-то навалил кучу, и нужно разбираться. Решение ничего не делать с NaN и возвращать false на любые проверки я считаю верным, потому что что ни придумывай, всё равно найдётся условие, при котором всё сломается. NaN невозможно обработать каким-либо способом, кроме как сказать "мы где-то обосрались в вычислениях", но это хорошая заглушка для возвращения результата математическими функциями для значений вне области определения. Математический null. Для null же нет логики кроме успешного срабатывания free()? Поэтому не вижу смысла вводить какую-то логику для NaN.

P.S. В С++ вон уже 20 лет пытаются предусмотреть "все случаи", а с каждым разом "случаев" появляется всё больше. Каждый раз как открываю cppreference и читаю "появилось в 2011, deprecated в 2017" начинет закрадываться сомнение по поводу адекватности авторов стандарта.