Если есть 2 способа сделать нечто, лично я предпочту тот что будет проще в понимании. Видимо ребята в Qt думают так же. Хотя нет, это не правда, ребята не использует шаблоны в Qt просто потому что как минимум некоторое время назад (а возможно и сейчас) вынуждены были работать на платформах с не самыми современными компиляторами. И кстати это же один из доводов против использования исключений.


Да, просто существуют вещи которые невозможно/сложно/не разумно сделать проще (по разным причинам).

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


Ну это разведение шаблонов позволяет делать бул точки. Нет шаблонов - нет проблемы.

Вообще, вы подходите к вопросу с точки зрения типичного с++ кодера - надо всё зашаблонить не думая о последствиях. В данном примере шаблоны не нужны. А, например, QAtomicInt имеет шаблонную базу QAtomicInteger<T>. Кстати, начиная с 5.3 он публичный.

define "встроенный". Мембер что ли? У QPointF нет мембер operator ==
Если built-in то такого тоже не существует для точек.

А, тьфу, это я читать не умею:) Был сконфужен что это в теме про точки) Про флоат\дабл вопрос абсолютно стандартный.

К сожалению, Вы нам не подходите. Мы ищем специалиста по разработке приложений для микроконтроллеров/ПЛИС/GPU, где вообще нет целочисленных регистров и машинных команд для манипуляции целочисленными данными, а вся целочисленная арифметика реализована как частный случай операций над числами с плавающей точкой.

Для меня, как для инженера-математика, безусловно, не равны. Я, кончено, подозреваю, что Вы имеете ввиду случай побититового сравнения представлений этих чисел в 32 битных регистрах х86 совместимых процессоров... Ну так и задайте вопрос правильно, типа
"Какова точность кодирования мантиссы для формата данных single-pecision чисел с плавающей точкой в стандарте IEEE 754-1985 и как эта особенности сказывается на результате сравнения float переменных в различных реализациях С компиляторов"?

Для информации: на "равенство" этих чисел с точки зрения компилятора может влиять даже опции, с которыми производится компиляция.

Так что к сожалению, и тут Вы нам не подходите. Кроме того, у Вас присутствует симптомы известной серди разработчиков болезни "Floating point paranoia". Для своевременного принятия мер по её излечению настоятельно рекомендуется к прочтению эта статья http://habrahabr.ru/post/112953/.
Ну и позволю её кусочек тут процитировать: "Сейчас арифметика с плавающей запятой почти совершенна. Практически всегда наивный подход сработает, и программа, не учитывающая все ее особенности, выдаст правильный результат, а описанные подводные камни касаются только экзотических случаев".

Подозреваю что и на равенство числа с плавающей точкой не сравниваются без допусков в этом случае? И кстати про ПЛИС у меня в резюме ни слова, странное что вы меня вообще на собеседование позвали...


Нет, все гораздо тривиальней. Если я вам скажи что эти 2 числа это координаты пикселя на экране? В этом мы смело можем утверждать что эти числа должны трактоваться как эквиалентные.
Следующий вопрос: а эквивалентны ли  1.9 и 1.8?
Ответ: Иногда да, а иногда нет.
Да - если мы все еще оперируем координатами пикселя на экране.
Нет - если мы оперируем координатами пикселя на экране но например для SVG анимации.

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

to Igors:
Не все решения Qt правильные и идеальные. Те же View не идеальны и, я бы сказал, поверхностны.

А аргументы находятся, "потому что оно работает" ©.
Решения простые, низкий порог для понимания механизмов работы, возможность внесения исправлений. Оно работало, работает и будет работать. Мне лично нравится такой подход, пусть он и теряет в возможностях.

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