Хорошо, меняем QList<CInstance> на std::vector<CInstance *> или даже (извращенных) юников. Ну и какая разница? Индекс-то все равно не получить

В чем же его хреновость, "брат таланта" ? 

QList вектор для типов sizeof <= sizeof(void *), напр int, QString и др. Для остальных это аналог std::vector<T *>, т.е. хранится вектор указателей на неперемещаемые данные.

Ну вот, теплилась (слабая) надежда что-то услышать/почерпнуть, хоть какие-то "идеи", а все сразу сваливается в жевание (замшелой) матчасти

Добрый день

Класс имеет контейнер, размер может быть значителен. напр 100K. Эл-ты контейнера могут быть selected и подсвечиваться в UI. Недолго думая я сделал так

C++ (Qt)
class MyClass {
...
  QList<CInstance> mInstances;
  QSet<CInstance *> mSelectedInst;
...
};
 

Правда сам CInstance не может сказать он selected или нет, нужен MyClass. Ну и ладно, зато операции с selection вполне удобны.

Но через какое-то время нарисовалась проблемка - ряд операций (напр запись undo) требует индексы selection. Заменить QList на вектор не могу, CInstance должен быть неперемещаемым. Приходится искать индексы перебором, что конечно "не украшает" на 100K и более.

Есть мысли как лучше организовать selection ?

Спасибо

Пример
Ужасный код   (по крайней мере с точки зрения рекомендации выше). Ведь push_back выделяет память, пусть не каждый раз, но многократно. И по завершении ф-ции вызывается деструктор вектора, а значит безумно медленное delete !

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

Зачем же давать рекомендации которым сами не следуем?  

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

Никто не заставляет все время выделять, можно  это сделать один раз. Да и выделять не смертельно (тыкающий знаток выше злорадно шутит), эти затраты намного меньше 1 мс

Здесь этой проблемы нет

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

А так и есть  (оставлено для совместимости со старым кодом). Только что толку от знания соседей - они такие же KeyFrame(s). Менять надо данные (KeyFrame) принадлежащие др KeyList которым владеет др KeyChannel

Видимо очередной пост "для оживления форума" 

Ну позиция "непонимающего" довольно удобна 

Пример

C++ (Qt)
void KeyList::CalcVelocity( ...)
{
  ..
  SetKeyTime(keyIndex, time);
  ...
}

Какие претензии к KeyList ? Он владеет всеми ключами (KeyFrames), знает что делать (CalcVelocity) - ну он время ключей считает и ставит, не вижу тут никакой  (архитектурной) ошибки. Проблема в том что KeyList никак не может связаться с др KeyList'ами что принадлежат др KeyChannel'ам.

ChannelsAndFramesManager - ну класс сбоку (припеку) никогда не выглядит хорошо  Он ничем не владеет, ничего не имеет - как он может что-то решать? Ну допустим заменим SetKeyTime на ChannelsAndFramesManager::SetTime, що це дало? Связки как не было так и нет

Не вижу энтузиазма Оно и понятно, вот "почитать", а еще лучше "собирать" - то да, а тут такая бяка... Ну ладно, покатаем очевидное

Вот класс самого верхнего уровня KeyChannel. Для него послать сигнал - без проблем, т.к. он имеет уникальный id, его видят в UI и.т.п. Попробуем так

C++ (Qt)
void KeyChannel::SetNthKeyTime( int keyIndex, double time );

Но менять KeyFrame::m_time только так я не могу - есть еще KeyList что меняет m_time когда захочет. А нужен ли KeyList? Да, KeyChannel может иметь нулевой KeyList (типа нод дерева, контейнер др KeyChannel(s)). KeyList может свапаться и существовать сам по себе. Да и вообще, пусть KeyList занимается KeyFrame(s) - эл-тами своего контейнера, а всякие там m_name, m_id - это уже др уровень. (мухи отдельно и все такое)

Ладно, еще вариант

C++ (Qt)
struct KeyFrame {
..
  double m_time; 
  double m_value; 
  KeyList * m_owner;
.. 
};

И аналогично для KeyList. Так получаю массу забот напр на операциях copy/paste - все время надо присматривать за m_owner что может оказаться хлопотно и ненадежно.

Что интересно - возникшая задача (реагировать на изменения времени ключа) - довольно скромная фича, неужели для нее надо менять так принципиально?
Ну так хорошо, предлагаем "некорявую". И тут ответ(отмазка) известен
Что на деле означает "будет жрать std и ни хрена не делать" 

Не знаю, может квадраты будут лучше, может нет. Во всяком случае квадраты (дисперсия) устроит. Да, тогда напрашивается МНК, но как его зарядить - не знаю. Вообще "строго оптимального" решения не требуется, достаточно "разумного"

Добрый день

Есть 2 контейнера сортированных int'ов, нужно добавить или удалить эл-ты второго так чтобы их число стало равно первому, и сумма разниц между эл-тами первого и второго контейнеров была минимальной. Значения одного контейнера не могут повторяться

Спасибо

Добрый день

Предельно упрощенно - классы "линейки времени"

Само/собсно время + значение

C++ (Qt)
struct KeyFrame {
..
  double m_time; 
  double m_value; 
.. 
};

KeyFrames хранятся в контейнере

C++ (Qt)
struct KeyList {
..
 Container<KeyFrame> m_keys;
.. 
};

И предъявляются в UI в виде "анимационного канала"

C++ (Qt)
struct KeyChannel {
 QString m_name;
 int m_uniqueID;
..
 QScopedPointer<KeyList> m_list;
.. 
};

И вот возникает задачка - когда юзер меняет время m_time одного (или нескольких) KeyFrame(s) (для заданного/специфичного канала)- нужно автоматычно пересчитать значение(я) в др канале. Варианты:

1) "Полный ручняк" - найти все места где меняется m_time и присобачить к ним if'ы. Однако мест таких ожидается по меньшей мере десятки. Да и латки if'ами не выглядят хорошо

2) "Полный автомат" - делать изменения в сеттере KeyFrame::SetTime. Но KeyFrame не знает кому он принадлежит, впрочем  KeyList тоже. Также "target" (кого надо менять) может отсутствовать (напр на загрузке)

3) "Месяги/Сигналы" - то же что в "2". Послать.. а кому? И что?

Что посоветуете?

Спасибо

У меня так не вышло (OSX), ни canonicalPath ни absolutePath "полного имени" не дают (или не гарантируют). Напр

/Volumes/Macintosh HD/...
/Users/igor/...

Для того же файла. Помогло QStorageInfo::displayName

Опускаю часть ответов чтобы не "растекаться"
Если Вы хотите "адаптивно", то хранить просчитанные точки - обязон. Стандартная техника octree (вариант multi). Оно также позволяет находить ближайших, но с учетом их радиусов, это мощнее чем kd-tree, хотя и ресурсов тратится намного больше. Регулярная сетка плоха своей "корреляцией", грубо говоря кто-то может вклиниться между рядами/столбцами. Да и "сгущать" ее довольно геморно. Другая крайность - чистый рандом, дескать
Это совсем не так, просто случайными ничего не добиться. Да, случайную не обманешь как регулярную, но она очень слаба "на восстановление", заполнить "пустоты" не удается даже при громадном числе точек. Octree предоставляет удобное решение/баланс. Даже если перебирать исходные точки с постоянным шагом и радиусом - все равно получится достаточно "живописная" картина отобранных (для расчета) точек. Вот правда "разпоточивание" этого шага нетривиально.

Будьте добры, удалите ту хрень что Вы дальше написали. Не лезьте в говно что называется политикой. Этот форум (слава богу) для этого не предназначен