GLM + STL: оператор == отсутствует

Question

Я пытаюсь использовать векторные классы GLM в контейнерах STL.Ничего страшного, если я не пытаюсь использовать <algorithm>.Большинство алгоритмов полагаются на оператор ==, который не реализован для классов GLM.

Кто-нибудь знает простой способ обойти это?Без (пере) реализации алгоритмов STL: (

GLM - отличная математическая библиотека, реализующая функции GLSL в c ++

Обновление

Я только что узналчто glm на самом деле реализует операторы сравнения в расширении ( здесь ). Но как мне использовать их в stl?

Обновление 2

Этот вопрос был заменен этим: как использовать оператор glm == в алгоритмах stl?

Answer 1

Многие алгоритмы STL принимают функтор для сравнения объектов (разумеется, вам нужно соблюдать особую осторожность при сравнении двух векторов, содержащих значения с плавающей точкой на равенство).

Пример:

Сортировкаstd::list<glm::vec3> (зависит от вас, будет ли сортировка векторов таким способом иметь какой-либо практический смысл), вы можете использовать

std::sort(myVec3List.begin(), myVec3List.end(), MyVec3ComparisonFunc)

с

bool MyVec3ComparisonFunc(const glm::vec3 &vecA, const glm::vec3 &vecB)
{
 return vecA[0]<vecB[0] 
        && vecA[1]<vecB[1] 
        && vecA[2]<vecB[2];
}

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

Answer 2

Вы должны иметь возможность реализовать оператор == как отдельную функцию:

// (Actually more Greg S's code than mine.....)

bool operator==(const glm::vec3 &vecA, const glm::vec3 &vecB) 
{ 
   const double epsilion = 0.0001;  // choose something apprpriate.

   return    fabs(vecA[0] -vecB[0]) < epsilion   
          && fabs(vecA[1] -vecB[1]) < epsilion   
          && fabs(vecA[2] -vecB[2]) < epsilion;
} 

Answer 3

Джеймс Керран и Грег С. уже показали вам два основных подхода к решению проблемы.

• определяют функтор, который будет явно использоваться в алгоритмах STL, которые в этом нуждаются, или
• определяют действительные операторы == и <, которые используют алгоритмы STL, если не указан функтор.

Оба решения прекрасно работают и идиоматичны, но при определении операторов следует помнить, чтоони эффективно расширяют тип.Как только вы определили operator< для glm::vec3, эти векторы расширяются для определения отношения «меньше чем», что означает, что каждый раз, когда кто-то хочет проверить, является ли один вектор «меньше» другого, он будет использоватьваш оператор.Поэтому операторы должны использоваться только в том случае, если они универсально применимы.Если это всегда единственный способ определить менее чем взаимосвязь между трехмерными векторами, сделайте это оператором.

Проблема в том, что, вероятно, это не так.Мы могли бы упорядочить векторы несколькими различными способами, и ни один из них не является «правильным».Например, вы можете упорядочить векторы по длине.Или по величине x, в частности, игнорируя y и z.Или вы можете определить некоторые отношения, используя все три компонента (скажем, если ax == bx, проверьте координаты y. Если они равны, проверьте координаты z)

Не существует очевидного способа определить, является ли один вектор«меньше» другого, поэтому оператор, вероятно, является неправильным путем.

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

Единственная проблема здесь состоит в том, что векторы состоят из значений с плавающей запятой, и поэтому вы можете захотеть сделать что-то вродесравнения эпсилон, поэтому они равны, если все члены равны почти .Но тогда вы также можете захотеть, чтобы эпсилон был переменным, а это невозможно сделать в operator==, так как он принимает только два параметра.

Конечно, operator== может просто использовать какой-то видзначение эпсилона по умолчанию и функторы могут быть определены для сравнения с переменными эпсилонами.

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