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

CC>Здравствуйте, мыщъх, Вы писали:

М>>но для плавучки в общем случае нельзя использовать '=='.
CC>Для того, чтоб узнать что число не изменилось — можно.
CC>Еще простая проверка на NaN делается сравнением числа с самим собой. Если (a != a) — то a == NaN.
Или одна из бесконечностей

CC>>Еще простая проверка на NaN делается сравнением числа с самим собой. Если (a != a) — то a == NaN.
S>Или одна из бесконечностей

Ну в формально логике эта фраза верна, как и фраза Если (a != a) — то a == NaN или небо зеленое.
Но в обычной логике это не верно:

$ cat infeqinf.cc 
#include <math.h>
#include <iostream>

int main() {
  float x = FP_INFINITE;
  std::cout << (x != x) << std::endl;
  return 0;
}

$ g++ infeqinf.cc 
$ ./a.out 
0

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

CC>>>Еще простая проверка на NaN делается сравнением числа с самим собой. Если (a != a) — то a == NaN.
S>>Или одна из бесконечностей

D>Ну в формально логике эта фраза верна, как и фраза Если (a != a) — то a == NaN или небо зеленое.
D>Но в обычной логике это не верно: ...

Перечитайте ветку. Оба комментария относились не к логике а к

foo(TYPEA a){ return ((a + 1) == a); }

Этот код может быть проверкой

• или на NaN, но использовать для проверки на NaN я бы не стал, поскольку это может привести к исключительной ситуации (в некоторых реализациях javascript, если мне не изменяет память то в ИЕ).
  
• или на бесконечность, которая по спекам, вроде как, не обязана равняться сама себе, иными словами после компиляции вашей программы в другом окружении, она может вывести истину.
  
• или проверкой на ошибку округления.

P.S. По поводу "обычной логики" -- у нас за такое с первого курса отчисляли
P.S.S. Это не укол вам, а реально моего сокурсника отчислили за такое словосочетание.

S>

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

это не так:

Comparisons are exact and never overflow or underflow. Four mutually exclusive relations are possible: less
than, equal, greater than, and unordered. The last case arises when at least one operand is NaN. Every NaN
shall compare unordered with everything, including itself. Comparisons shall ignore the sign of zero
(so +0 = −0). Infinite operands of the same sign shall compare equal.

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

S>>

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

D>это не так:

D>

D>Comparisons are exact and never overflow or underflow. Four mutually exclusive relations are possible: less
D>than, equal, greater than, and unordered. The last case arises when at least one operand is NaN. Every NaN
D>shall compare unordered with everything, including itself. Comparisons shall ignore the sign of zero
D>(so +0 = −0). Infinite operands of the same sign shall compare equal.

Согласен, эт я хну сморозил Перепутал с NaN.

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

Pzz>Во-первых, надо мозги иметь, чтобы различать, когда использовать стандартную запчасть, а когда свою вытачивать.

TL>... А "свою вытачивать приходится" — это в основном от незнания стандартных и главное от _непринятия_ знания, что оные вообще существуют.

Pzz дело говорит, зря с ним споришь — не нужно скатываться в другую крайнюю область.
Я видел несколько проектов, которые погибли/были переписаны именно из-за тупого необдуманного желания использовать множество "стандартных компонентов", в тот момент, когда такие компоненты не удовлетворяли ТЗ даже в самых радужных расчетах.
Так что я бы выделил сие в два пункта:
1) желательно применять анализ — для того, чтобы понять, целесообразно ли в данном конкретном проекте использовать тот или иной "стандартный компонент", или нужно наресерчить свой, или нужно взять какие-то конкретные решения и их допилить(как вариант — обратиться к их владельцам с фичреквестом);
2) анализ рекомендуется делать мозгом.

Из-за велосипедистов бывает вред, бывает много вреда, особенно эта болезнь распостранена среди начинающих девелоперов. Из-за фанатиков антивелосипедистов вреда тоже нормально, где-то 25/75, я думаю... причем с возрастом и опытом эта болезнь обычно усугубляется.
Хотя от сферы применения, наверное, тоже сильно зависит, вобщем-то это имеет прямое отношение к черезчур громкому слову "инновации".