Нашли или выдавили из себя код, который нельзя назвать нормальным, на который без улыбки не взглянешь? Не торопитесь его удалять или рефакторить, — запостите его на говнокод.ру, посмеёмся вместе!
+52
int QTabBarPrivate::indexAtPos(const QPoint &p) const
{
Q_Q(const QTabBar);
if (q->tabRect(currentIndex).contains(p))
return currentIndex;
for (int i = 0; i < tabList.count(); ++i)
if (tabList.at(i).enabled && q->tabRect(i).contains(p))
return i;
return -1;
}
currentIndex - видимо откат заплатил
PS
Cкоро всю Qt на говнокод заливать придется.
Плохое настроение или хотите поржать - открывайте исходники Qt в случайном месте - поднимаете себе настроение идиотскими решениями - профит
Запостил: 
fsmoke,
23 Ноября 2014
Follow us!
Это оптимизация на самом деле. Поскольку текущая вкладка будет тыкаться мышкой чаще, проверяем сначала её, а потом вс остальные - за время O(n).
А лопата в O(n) вместо O(log n), который якобы можно получить, если использовать двоичный поиск вместо линейного.
Я когда-то велосипедил QGraphicsFramework (типа 2D движок) на голом API, для поиска пересечений тоже использовал тупой линейный поиск вместо построения полноценного BSP. Сцена держала тысячу статичных объектов, по которым можно было возюкать мышкой хоть до посинения, они достаточно быстро ловили события mouseIn, mouseMove и mouseOut и никто по производительности не обломался.
fsmoke просто прикапывается к мелочам.
P.S. BSP дороговато вроде обновлять... Я вообще тупо разбивал мир на квадратные клетки. А десяток объектов, задевающих клетку, тестил за O(n).
да, я разбивание на клетки и имею в виду
Можно поподробней? Что-то я эту выкладку не понимаю.
> Что-то я эту выкладку не понимаю.
32 бита, 16 по оси X и 16 по оси Y. Каждый бит полухеша - принадлежность объекта соответствующей строке или столбцу. Таким образом простым XOR выясняется, пересекаются ли объекты в первом приближении, или нет. Такой способ позволяет иметь объекты размером больше клетки или учитывать их переползание из одной в другую.
Эта штука юзалась и для предварительного просчета коллизий и чтобы узнавать, какие объекты попали во вьюпорт и их надо передать клиенту.
Я просто совсем уж на производительность хотел задрочить, чтобы у объекта можно было узнать хеш без обращения к глобальной таблице.
А это уже Quad Tree.
Поэтому я просто в кажой клетке хранил массив тех, кто её задевает, всё просто.
Уже давно применяю в своих играх) Чтобы даже 10-кратное увеличение уровня, заполненного 10-кратным числом монстров, никак не влияло на скорость обновления.
Карочи 4-связный список. Позволяет быстро объект вытащить из всех клеток и запихать в другие, например.
А у меня была всего одна процедурка, которой передавались 2 rect'а - новый и старый. Плюс вторая такая же для вьюпортов (клетки хранили 2 списка - кто видит клетку и кто ее касается).
Объект впиливался в те клетки, которые касаются нового, но не касаются старого и выпиливался из касающихся старого, но но задевающих новый. Примерно так.
Жалко, что я положил хуй на этот проект ;(
P.S. Одновременно с этим вьюпорты получали уведомление о появившихся в поле зрения объектах (и о пропавших из него).
мой моск порвался на четвертом перечитывании
Теперь - да. Это я его только что так окрестил ;)
P.S. Можно назвать двумерной поебенью Тараса, если так больше нравится.
Разбил бы по смыслу. По памяти и пирфомансу просадочка, но зато быстро пишется. А оптимизировать в тарасоструктуру никогда не поздно.
Сам же я тоже затруднялся это назвать: http://www.gamedev.ru/flame/forum/?id=181764
в итоге назвал tblib::list2d, причём он внутри себя хранит пул для объектов, тоже говно, по хорошему надо передавать аллокатор в шаблон, но я не умею аллокаторы
Ну просто хеш-мапа+связный список. Помнит порядок добавления элементов. Удобно для всяких LRU-кешей.
Но у тебя ж в двух измерениях. А я предлагаю разбить на две независимые коллекции, но в которых можно быстро искать нужный ключ, что есть переголова.
Если надо получить соседей по второму измерению (срезу) надо при итерации по первому списку взять этот элемент, пойти в другую мапу и за O(1) найти его.
>>Простой двунаправленный список - это список из элементов, состоящих из
>>1. указателя на муху
>>А я подумал, а что если сделать список таких элементов:
>>1. указатель на муху
БЛДЖАД, ЭТО ЖЕ ЛЕГЕНДАРНЫЙ АЛГОРИТМ МУХИ!!! Он тоже работает верткально и горезотально.
Как видишь.кидаем в праграмму (праграмму пока пишу) программа откидивает то что всегда есть,
двух, четерех одинакывые байты сокрощает по горезаталь, вертекально: разбивет их на две стопки сокращая их; и 5,6 с 16,17 тоже сокращает: (алгаритом прицимп мухи)
52 61 72 21 1A 07 00 CF 90 73 00 00 0D 00 00 00
00 00 00 00 6C 35 74 20 90 33 00 41 00 00 00 00
04 00 00 02 7D 82 04 DE 42 65 A4 44 1D 35 0E 00
20 00 00 00 72 75 6E 70 72 6F 6A 65 63 74 2E 72
75 70 00 F0 BE 5B 5D 09 01 54 CB E4 CD C8 9A 66
0A DB 29 69 94 A0 88 FF D0 82 24 FA 7B F2 6F F0
92 A5 C4 D3 BB 40 EC 3F 9D A6 BC 26 E4 36 DE 15
E8 73 4F 43 C4 EB 21 F2 C1 4F 6B 17 AC DA 80 B6
6E 43 97 EF 63 EB DE C8 C4 3D 7B 00 40 07 00
тоесть как видит муха: онавидит виде 2000 ячек вглазу разбитых и вкаждой изброжение прамма скро появится
клеток можно сделать сколько хошь, лишь бы смысл был, потому что если для каждого пикселя хранить все перекрывающие его окна, то смысла никакого и двигать окна дороговато
ЗЫ
а Q_Q кстати , это чеширский говнокот, это самый говенный паттерн и всех, имхо
private implementation - паттерн неприятный, не спорю, но во многих классах вынужденный. Без него всякое говно из windows.h будет торчать из всех ашек и засирать глобальный неймспейс.
Оно для этого и запилено.
Это когда в *.h пишут, что у класса поле void*, а с *.cc инклюдят много грязных файлов и пишут, что это то поле - typename T<X, Y<std::vector>, Z>::pointer?
http://en.wikipedia.org/wiki/Opaque_pointer