Вы не должны полагаться на NaN
, чтобы сделать работу. Он всегда будет сравнивать false с любым значением, в том числе и с самим собой, и вы должны убедиться, что платформа в определенной степени учитывает семантику IEEE754 (это включает в себя наличие NaN в первую очередь).
Смотрите там ужасные истории: Отрицательный NaN - это не NaN?
Если вам действительно нужен такой подход, и вы достаточно уверены в поддержке IEEE754, обязательно скомпилируйте с /fp:precise
(поскольку вы используете MSVC), чтобы компилятор не оптимизировал такие вещи, как 0 * NaN
. Помните, что это может повлиять на производительность.
Чтобы получить NaN,
std::numeric_limits<double>::quiet_NaN()
Для проверки на NaN
inline bool is_NaN(double x) { return !(x == x); }
Но такой подход, вероятно, доставляет больше хлопот, чем стоит. Я бы предпочел использовать исключения для потока управления здесь.
Правильно использовать boost::optional<double>
, но в некоторых местах он может быть немного многословным
[Кроме того, язык Haskell имеет первоклассную поддержку для такого потока управления, если C ++ не является обязательным параметром, Maybe
, вы можете попробовать его.]