Russian Qt Forum

Добрый день

Навеяно соседней темой. Не избегает ли Qt темплейтов где только можно? Ну хотя бы

QPoint - QPointF
QRect - QRectF

Казалось бы, ну явный, махровый template, ведь отличие только в типе данных. Но нет, в Qt это не template. Задавая этот вопрос раньше, получал только ответы типа std::борзость, напр
Но я все-таки спрошу еще раз  :)

Спасибо

Задавался такой вопрос троллям довольно давно - почему бы не навалить темплейтов, увязать всё это бустом и проапгрейдить до нужного уровня.
Ответ - Qt должен быть простым и понятным. Их цель - не красота кода, а простота и универсальность.

wat?


Окей, мы получим Point<int>, Point<long>, Point<bool>, Point<void> ну и так далее. Всё это надо как-то между собой увязать (логично, что можно складывать разные точки и получать точку большей размерности). Оно нам надо?

Не понял откуда взялась проблема какой-то увязки.

Думается "шо?" звучало бы гораздо лучше  :)

Не "Шо?", а вопрос - почему вы не пользуетесь бустом, звучал. Ведь если замешать буст, темплейты и Qt родится такая уникальная мешанина :D

Но тролли сказали что хотят Qt, а не мешанину :)

Потенциальный вопрос для собеседований:
Какой оператор правильно использовать для операций над целочисленными типами, и не совсем правильно выполнять для чисел с плавающей точкой?
Ответ: operator ==
Вопрос к ответу: Почему?

Point<int> p1(10, 10);
Point<qlonglong> p2(20, 20);
auto p3 = p1 + p2; // какой тип у p3?
Point<bool> p4; // можно ли так объявить?
Point<void *> p5; // а так?
Point<void> p6; // а вот так?
auto p7 = p1 + p5; // какой тип?

К сожалению, вы нам не подходите.

Но позвольте, для этого есть template<> (специализация шаблонов?), которую некоторые здесь с упоением рисуют при первой же возможности.

Ну то есть нам надо специализировать void, T *, возможно, bool. То есть уже 4 класса. А было 2.

Да тот же самый что сейчас (если это сейчас работает). Вариант-минимум

C++ (Qt)
typedef TPoint <int> QPoint;
typedef TPoint <qreal> QPointF;

И пусть все остальное как сейчас. Найдется немало ф-ций где удобнее template аргумент вместо дублирования и/или копирования туда-сюда

Если возникает такое страстное желание сделать bool точку (что это?), а тем более void  ???, то вот пусть автор и "специализирует", какой смысл он в это вкладывал - хз

Угу, и мы получим вместо двух потенциально простых для понимания классов, 2 несколько более сложных шаблона, да еще один их которых специализирован по типу. Сколько джуниоров сломает себе мозги на этом ровном месте?

Каюсь, как это зачастую бывает на собеседованиях, вопрос был недостаточно точен:
Какой встроенный оператор...

А зачем джуниору что-то ломать? Он может спокойно пользоваться теми же самыми QPoint и QPointF - с той лишь разницей что они будут typedef, И откуда два шаблона ??? Да, и тот же Qt вовсе не стесняется "трудностей с пониманием",  см напр во что выливается Q_DECLARE_METATYPE

Два шаблона - потому что неправильно сравнивать double через ==, поскольку статистически два double с большой долей вероятности будут не равны, но отличатся могут на бесконечно малое значение, которое может считаться приемлемым. А значит математика для int и для double будет разная, а значит будет шаблон, и его специализация для чисел с плавающей точкой, т.е. как минимум 2 шаблона.

Если тезис про то что использовать == с double нежелательно звучит для вас бредом - могу пояснить на примере.

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


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

Что значит "не совсем" правильно? Для какой аппаратной платформы? Для какого компилятора?

Что такое "встроенный" оператор? Во что встроенный?

Такого рода вопросы - отличная тема для беседы с потенциальным новичком, но отнюдь не повод ожидать от него "правильных" ответов.

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


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

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

Платформа и компилятор значения не имеет.

Для примера, скажите, равны ли два числа 1.999999998 и 1.999999991 ?


встроенный в моем понимании это не перегруженный.

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

речь шла о сравнении примитивных типов через ==

P.S. похоже я все же плохо умею выражать свои мысли...

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

Уфф, отлегло... ;)

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

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

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

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

Приведите, с удовольствием послушаю. Добавлю что разница не только в этом - напр деление int на ноль выбрасывает исключение, а для флотов нет.

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

Это весьма слабый аргумент даже для такого "нелюбителя" темплейтов как я. Специализировать всего неск ф-ций - просто мелочь по сравнению с дубляжом десятков и десятков членов класса, 99% которых идеально совпадают. Да, и вот понадобится TPoint <float> (напр с OpenGL это вероятно), и что бум делать?

И еще позвольте спросить (RSATom, не Вас личнo, а всех участвующих). Ну а почему любое решение Qt считается правильным и идеальным? Почему так охотно отыскиваются аргументы "в одну сторону" а "в другую" не рассматриваются вообще?

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


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

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

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

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

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

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

Оказывается есть даже такая болезнь: "Укушенный Александреску" :)

Нет такой болезни, есть неприятный опыт работы с шаблонами :)

http://rsdn.ru/forum/cpp/5638123.1

С этим никто не спорит. Не так давно у меня был случай: QCursor::pos() выдает другое значение чем event->pos(). Оказывается OSX выдает позицию мыши во флотах, и проблемы с округлением. Но ведь наличие 2 классов (QPoint и QPointF) никак не спасло меня. Др словами эти проблемы так или иначе надо решать, не видно как это связано с "template или нет"

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

Так ведь у Вас в резюме стоит "Знание С++ - на уровне способности проводить собеседования кандидатов" и нигде не написано, что для Вас "С++" это только x86. Извините, что заняли Ваше время, просим далее быть более конкретным в оценке своих навыков.

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

Это я всё к тому, что стоить посмотреть как трансформировался Ваш "тривиальный" вопрос, предполагавший не менее "тривиальный" ответ.

Ну так об этом и речь: "Ответ: Иногда да, а иногда нет."

Ок, переформулирую: Как осуществляется сравнение на равенство целочисленных типов на платформах без поддержки целочисленных вычислений?

Как я и говорил ранее - целочисленные типы рассматриваются как частный случай float. То есть там int - это float, с дробной частью, равной нулю. Поэтому правильный ответ - в зависимости от реализации этого сравнения компилятором и даже от параметров компилятора. Условно говоря, для -O1 - это может быть одна реализация сравнения, а для -O3 - вообще совершенно другая. И говорить про "поведение по-умолчанию" даже для примитивных типов можно только для совершенно конкретной комбинации компилятора и платформы.

Это только довод в пользу того что этому вопросу необходимо уделять специальное внимание. Соответственно изначальный тезис о том что "надо просто использовать template и будет счастье" все же не верен. Что и требовалось доказать.

Кстати, а как решается вопрос что не всякое целое число можно представить в виде числа с плавающей точкой?

Ладно, оффтоп так оффтоп, все равно "говорилка". Давайте и я про флоты,

C++ (Qt)
float a, b;
...
a = (b < 0) ? 0 : sqrt(b);
 

C++ (Qt)
float a, b;
...
a = sqrt(b);
if (b < 0) a = 0;
 

Есть ли здесь какая-то разница или дело только в оптимальности?

Нэкоррэктно, такого тезиса я не выдвигал :) Возьмем напр "int" и "long long", Вы знаете, они ведь тоже не равны и могут иметь разное поведение. Выходит им тоже "необходимо уделять специальное внимание", и тоже темплейт нехорош. Может лучше прямо сказать "та ну его нафиг, тот темплейт", как (по существу) делает Верес  :)

По поводу оператора == для флоатов и даблов, имхо, проблема чисто языковая. Стандарт С++ просто ничего не говорит об особенностях его применения для данных типов, и как следствие, оператор становится неипользуемым. Все пишут свои велосипеды fuzzy сравнивания. Как по мне, было бы идеально ввести в сам язык понятие fuzzy сравнения для вещественных типов по умолчанию. Т.е. по умолчанию компилятор будет генерировать нужный код сам, встретив что-то типа "if (a == 0.05)..", с точностью сравнения, определенную стандартом языка (например, std::numeric_limits::epsilon). Если кому недостаточно - тогда пожалуйста, make a bike :)

Я провожу сравнения с помощью ==, без фузи.
Но не просто так. После считывания текстового файла.

Тут и компилятор не нужен, это поддерживается самим форматом флотов. Напр

C++ (Qt)
float test1 = 21234567.8901f;
float test2 = nexttowardf(test1, test1 * 2);
printf("%f\n", test2 - test1);
 
printf("(test1 == test1 + 1) = %d\n", int(test1 == test1 + 1));
 

Не, я имел в виду "нативное" сравнение флотов как средство языка. Чтобы запись не отличалась от математической:

float a, b;
...
if (a == b)...

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

Это недостижимо из-за самого формата флотов (ну или "их природы"). Еще раз тот же пример

C++ (Qt)
float a, b;
...
b = a + 1;
if (a == b)  // для флотов может вернуть true

Др словами если мы хотим хранить гигантское число - мы должны смириться с потерей точности, это нормально

Формат флотов это понятно, но я не имею в виду "побитное" сравнение - иначе сравнение инта с флотом тоже никогда бы не работало, хотя и инт, и флот по умолчанию оба занимают по 4 байта. Для сравнения инта и флота компилятор генерирует код, который гарантирует приведение флота к инту непосредственно перед выполнением операции сравнения. Собственно, то же самое можно делать при сравнении двух флотов - сгенерировать базовый фузи-код. Естественно, с потерей точности.

Наоборот, инт приводится к флоту  :)

Фузи-фузи, а что в нем собственно такого хорошего? Для больших чисел он вообще бесполезен а для малых проблематичен.

Например, a = 0.123456789000001, а b = 0.123456789000002. Ну или около того. В текущей имплементации оператор if (a == b) вернет false, в принципе с одной стороны они и правда не равны, с другой - отличаются достаточно незначительно. Поэтому и пишет народ фузи типа if (qAbs(a-b) < MyLittleEpsilon). То есть оператор == вообще не используется должным образом, и как по мне, это недостаток. Компилятор должен сам уметь генерировать подобный фузи-код для сравнения флотов, встретив if (a == b).

Я понимаю что Вы хотите, но думаю что здесь нет удачной возможности "единого решения". Что есть "достаточно незначительно" определяется задачей. Напр Qt реализация вполне хороша/грамотна, но

C++ (Qt)
float a = 100.0f;
float b = 100.005f;

Qt fuzzy скажет что равны - но есть масса примеров где это не устроит. А раз так - нечего рыпаться на "общность" - это конкретно (и нолрмально)

В STL существует стандартное значение std::numeric_limits::epsilon. Его было бы достаточно. Если кого не устраивает - пишем свой фузи :)