Сложить 2 QColor

[Igors]

Точно, именно на это я намекал.

Что-то слишком тонко 

Эммм... Вам не кажется, что вы только что описали qRgb классик?

Как всегда не въехали и не разобрались. qRgb здесь не годится

И к чему эта тафтология, если всё равно ваш "оператор", который вы не привели

Как всегда верещите и захламляете тему 

[Bepec]

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

[Old]

Что-то слишком тонко 

Тонко?? Да по моему толще не куда:

Все зависит от контекста его использования (оператора+): для эпизодического сложения двух цветов - он хорош, для складывания массива цветов на время - плох.
Как, в прочем, и все в программирование.

[Igors]

Все зависит от контекста его использования (оператора+): для эпизодического сложения двух цветов - он хорош, для складывания массива цветов на время - плох.
Как, в прочем, и все в программирование.

Не вижу чем Ваш оператор плох для сложения массива - да, вероятно альфа быстро переполнится, но все RGB сложены будут. Др дело напр так

Код

C++ (Qt)
QColor average = (c1 + c2) / 2;
 

Это не дает правильный результат, поэтому лучше не начинать городить операторы, а ограничиться ф-цией.
 
А с концепцией/философией я конечно согласен  

[Old]

Не вижу чем Ваш оператор плох для сложения массива

Тем, что для массива можно написать более эффективную реализацию.

Др дело напр так

Код

C++ (Qt)
QColor average = (c1 + c2) / 2;
 

Это не дает правильный результат, поэтому лучше не начинать городить операторы, а ограничиться ф-цией.

Для начала нужно понять, что здесь происходит, а потом уже разбираться, почему это не дает правильный результат.

[Igors]

Для начала нужно понять, что здесь происходит, а потом уже разбираться, почему это не дает правильный результат.

А это тоже непонятно?

Код

C++ (Qt)
QPoint middle = (pt1 + pt2) / 2;
 

[Old]

А это тоже непонятно?

Код

C++ (Qt)
QPoint middle = (pt1 + pt2) / 2;
 

А как вам такое:

Код

C++ (Qt)
QPoint middle = (pt1 + pt2) ^ 2;
 

[Igors]

А как вам такое:

Код

C++ (Qt)
QPoint middle = (pt1 + pt2) ^ 2;
 

А вот в книжках пишут что перекрытые операторы должны иметь точно такой же смысл как в C, т.е. как для простых типов (напр int, double). А поскольку Вы знаете в 100 раз больше - Ваш намек на неоднозначность оператора / меня удивляет 

[Old]

Ваш намек на неоднозначность оператора / меня удивляет 

Для цвета он не однозначен. Да. Также, пожалуй, как и для точки.
Ну не понимаю я как цвета можно складывать, умножать и делить.

[Igors]

Для цвета он не однозначен. Да. Также, пожалуй, как и для точки.
Ну не понимаю я как цвета можно складывать, умножать и делить.

Любую точку можно представить как вектор из начала координат (0, 0, 0). То же самое и для цвета. А для векторов арифметика прекрасно определена и интуитивна.

Ну вот напр на мониторе видим 100% красный. Поделим на 2 - ну 50% красного. Добавим 100% зеленого, результат = оранжевый. Чего ж нельзя-то? 

[Old]

Любую точку можно представить как вектор из начала координат (0, 0, 0). То же самое и для цвета. А для векторов арифметика прекрасно определена и интуитивна.

Ну вот напр на мониторе видим 100% красный. Поделим на 2 - ну 50% красного. Добавим 100% зеленого, результат = оранжевый. Чего ж нельзя-то? 

Вы сейчас рассказали о соглашениях. Если о них сообщать в документации, то конечно это можно использовать.
А если в QColor лежит цвет в HSV, то что я должен додумать, видя его деление на 15?

[m_ax]

Я бы не стал для такого объекта, как цвет (ARGB) переопределять оператор +.
Во-первых, в отличии от вектора, для цвета нарушается коммутативность суммы:
например с1 + с2 + с3 неравно с1 + с3 + с2.
А это неожиданный для конечного пользователя результат уже может сломать ему мозг в поисках ошибки (а она рано или поздно случится)..

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

[Igors]

Вы сейчас рассказали о соглашениях. Если о них сообщать в документации, то конечно это можно использовать.
А если в QColor лежит цвет в HSV, то что я должен додумать, видя его деление на 15?

Ну так я и не предлагал делать никаких операторов для класса QColor, напротив, я считаю эту затею неудачной, о чем подробно сказал выше. Просто все (увы, включая Вас) начинают запрягать QColor, хотя это совершенно неуместно. Подобный эффект часто наблюдается и с др задачами/классами, напр QRegExp. Из инструментария выбирается класс наиболее подходящий - и (почему-то) автоматычно считается что использовать его = гуд. Но ведь это совсем не так. Собственно поэтому я и создал эту тему  

[Igors]

Я бы не стал для такого объекта, как цвет (ARGB) переопределять оператор +.
Во-первых, в отличии от вектора, для цвета нарушается коммутативность суммы:
например с1 + с2 + с3 неравно с1 + с3 + с2.
А это неожиданный для конечного пользователя результат уже может сломать ему мозг в поисках ошибки (а она рано или поздно случится)..

Согласен, но давайте смотреть ширше. Кто нас заставляет делать обрезку (вследствие чего получается неоднозначность)? Почему мы должны ютиться в рамках QColor который для этого совсем не предназначен? Давайте введем свой класс который не имеет проблем с арифметикой

[Old]

Ну так я и не предлагал делать никаких операторов для класса QColor, напротив, я считаю эту затею неудачной, о чем подробно сказал выше.

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

Еще в теме немного поучаствовал Верес, не не особо...
Поэтому я совершенно не понимаю, кто кроме вас начал запрягать QColor.