Нашли или выдавили из себя код, который нельзя назвать нормальным, на который без улыбки не взглянешь? Не торопитесь его удалять или рефакторить, — запостите его на говнокод.ру, посмеёмся вместе!
+14
void ThumbnailAdapter::clearCache(size_t index) {
if ((size_t)-1 == index) {
mImages.clear();
} else {
ImagesMap::iterator it = mImages.find (index);
if (mImages.end() != it) {
mImages.erase(it);
}
}
}годная очистка map'ы
Запостил: 
shomeser,
12 Марта 2013
Follow us!
как и имеет право erase(iterator) вместо erase(key)
зачем? если в ф-ю и так передается ключ?
но никто не знает, что афтор мог сделать с найденным элементом, подлежащим удалению
может вызовет it->prepare_to_die_bitch(), а может ничего не сделает
ценой всего лишь одной лишней строчки
ну и да, поведение двух удалений в случае, например, multimap будет разным :)
я исхожу из того, что приведенный гк полный, иначе ожидаю видеть строки:
>например, multimap
кто ж спорит, но о5 таки, речь тс шла про map, а не о чем-то другом
обычно set, multiset, map, multimap выполняются на одном базовом классе, реализующем rb-tree
поэтому size_t erase(key), сделанный в лоб, должен найти пару итераторов - границы где лежат элементы с этим ключом, затем найти distance (надо же вернуть число удаленных) + поудалять всё в этих границах (можно одновременно)
но что в 2 раза почти разница - это как раз удивительно, снова привет libstdc++?
Ну, в принципе, это объясняет проблему. Причем в libstdc++ походу в конец обленились, и запилили set через multiset, поправив insert'ы и добавив скобки.
set<> и map<> же по определению гарантируют, что в них ключ встречается только один раз, есть какая-то адекватная причина, по которой они не стали бы пользоваться этим знанием?
я на работе мельком студийную реализацию смотрел - там как раз примерно так, как я описал - xtree посрать уникальный или нет реальный контейнер, он ищет пару итераторов как границы
сравнивать надо удаление из копий s1.
http://liveworkspace.org/code/2vAxRR$5
последние две строки вывода: разницы в производительности (s3 v. s4) почти нет.
а можно поподробнее?
у s1 соседние узлы фрагментированны, т.к. он наполнялся рандомно
ему же исходное дерево надо обойти, каким бы способом он его не обходил, соседние узлы (родственные или сестринские) будут локализованы лучше рандомно аллоцированных
в этом способе каждый родительский элемент будет лежать рядом со своим правым, что уже неплохо
http://liveworkspace.org/code/9ZspQ$0
я это первый раз на своих доморощеных AVL деревьях заметил. два теста должны были давать одинаковую (и ассимптотически, и по количеству операций) производительность. но один тест работал стабильно на 10-20% медленее. после длительных разборок, разница свелась к тому в каком порядке элементы встявлялись, опходились.
у нас ещё встречались товарищи, которые -1 возвращали в качестве указателя
чтобы делать while (stream >> item) ..., при этом, не конфликтовало с приведением к int
в c++11 заменили на explicit operator bool ()
std::string::npos, например
такое нередко встречается в жизни, когда надо из беззнаковых чисел выбрать специальное