Не понял, зачем такой переход. В QVector, вроде, и так всё выровнено

Молодцы, спасибо!

Документацию нашёл в папке docs https://github.com/fralx/LimeReport/blob/master/docs/UserManualRu.pdf

QSqlRelationalTableModel для отображения всей таблицы из базы. Для отображения запроса QSqlQueryModel.
Можно, конечно, дальше сопротивляться и прикручивать костыли к таблице и страдать от выкачивания BLOB

Копирования на этапе поиска я побарывал так:
За счёт этого можно пользоваться шаблонным find и копирования не будет

Да, я понял, что много юниформов. Соответственно и locations будет много + возможно много избыточных


Я бы в таком случае использовал


Не работал с массивами, кроме как QVector3D, QMatrix4x4 и подобными - не знаю как выглядит эта зарядка. Я так понял по аналогии с этой

Вместо "light[1].amout" брать locations.light[1].amount

я бы отказался от SetUniform в пользу методов setDiffuse(float) и setAmountOfLight(size_t index, float), setAmountOfLight(float)

locations при линковке шейдера сохранить в структуру

glPolygonOffset, кстати у меня прям норм прижился. Немного повозился с подбором параметров на разных картах и больше не возвращался к нему.

Но не по 1К юниформов, подозреваю

Не понимаю, почему в const char * name удаётся отделаться строками. Вектор не мог бы хранить несколько location для этих структур?

Как вариант завести структуру со всевозможными location и вместо const char * name использовать её поля. Уродливо, но зато быстро

есть у меня ощущение, что в QOpenGLShaderProgram, glGetUniformLocation используется примерно та же мапа для поиска location по имени. Ещё думаю, не стоит исключать то, что может быть происходит обращение с видеокартой, на что тоже тратится время

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

Я пробовал объединять QOpenGLShaderProgram с её location в одном классе, у которого были методы setModelViewMatrix, setColor и т.д

Очень похоже, что Qt сам регистрирует QMatrix3x3

Нужно только сравнивать v.userType() с qMetaTypeId<QMatrix3x3>()

C++ (Qt)
template<class T>
bool SameValue( const QVariant & v, const T & value )
{
  return (v.type() == qMetaTypeId<T>()) && (v.value<T>() == value);
} 
 

Так работает?

Через std::set::extract обеспечивается. Делает возможным хранение объектов, а не указателей

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

Придётся исправлять, либо больше закапываться в местах обращения

Если node владеет curve, то можно ещё попробовать std::set<Curve>. Понадобится написать transparent компоратор, который будет их укладывать и искать по curveID или обойтись std::less<> в качестве компоратора и operator< для Curve, int и для Curve, Curve

ещё можно попробовать flat_set. Индексация будет быстрее, но в нём итераторы и указатели инвалидируются при модификации а также замедлится вставка/удаление. Под капотом у него вектор.

Ссылка протухла