- 01
- 02
- 03
- 04
- 05
- 06
- 07
- 08
- 09
- 10
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);
}
}
}
defecate-plusplus 12.03.2013 15:16 # 0
roman-kashitsyn 12.03.2013 15:19 # 0
defecate-plusplus 12.03.2013 15:23 # 0
как и имеет право erase(iterator) вместо erase(key)
absolut 12.03.2013 16:56 # 0
зачем? если в ф-ю и так передается ключ?
defecate-plusplus 12.03.2013 17:16 # +1
но никто не знает, что афтор мог сделать с найденным элементом, подлежащим удалению
может вызовет it->prepare_to_die_bitch(), а может ничего не сделает
ценой всего лишь одной лишней строчки
ну и да, поведение двух удалений в случае, например, multimap будет разным :)
absolut 12.03.2013 17:44 # 0
я исхожу из того, что приведенный гк полный, иначе ожидаю видеть строки:
>например, multimap
кто ж спорит, но о5 таки, речь тс шла про map, а не о чем-то другом
defecate-plusplus 12.03.2013 18:00 # 0
bormand 12.03.2013 18:36 # 0
defecate-plusplus 12.03.2013 19:54 # 0
обычно set, multiset, map, multimap выполняются на одном базовом классе, реализующем rb-tree
поэтому size_t erase(key), сделанный в лоб, должен найти пару итераторов - границы где лежат элементы с этим ключом, затем найти distance (надо же вернуть число удаленных) + поудалять всё в этих границах (можно одновременно)
но что в 2 раза почти разница - это как раз удивительно, снова привет libstdc++?
bormand 12.03.2013 20:13 # +1
Ну, в принципе, это объясняет проблему. Причем в libstdc++ походу в конец обленились, и запилили set через multiset, поправив insert'ы и добавив скобки.
set<> и map<> же по определению гарантируют, что в них ключ встречается только один раз, есть какая-то адекватная причина, по которой они не стали бы пользоваться этим знанием?
defecate-plusplus 12.03.2013 20:55 # 0
я на работе мельком студийную реализацию смотрел - там как раз примерно так, как я описал - xtree посрать уникальный или нет реальный контейнер, он ищет пару итераторов как границы
Dummy00001 13.03.2013 04:48 # +4
сравнивать надо удаление из копий s1.
http://liveworkspace.org/code/2vAxRR$5
последние две строки вывода: разницы в производительности (s3 v. s4) почти нет.
defecate-plusplus 13.03.2013 09:28 # 0
absolut 13.03.2013 11:20 # 0
а можно поподробнее?
defecate-plusplus 13.03.2013 11:45 # +5
у s1 соседние узлы фрагментированны, т.к. он наполнялся рандомно
absolut 13.03.2013 12:20 # 0
defecate-plusplus 13.03.2013 12:24 # 0
ему же исходное дерево надо обойти, каким бы способом он его не обходил, соседние узлы (родственные или сестринские) будут локализованы лучше рандомно аллоцированных
absolut 13.03.2013 13:14 # 0
defecate-plusplus 13.03.2013 13:42 # +1
в этом способе каждый родительский элемент будет лежать рядом со своим правым, что уже неплохо
http://liveworkspace.org/code/9ZspQ$0
absolut 13.03.2013 14:29 # 0
Dummy00001 13.03.2013 14:22 # 0
я это первый раз на своих доморощеных AVL деревьях заметил. два теста должны были давать одинаковую (и ассимптотически, и по количеству операций) производительность. но один тест работал стабильно на 10-20% медленее. после длительных разборок, разница свелась к тому в каком порядке элементы встявлялись, опходились.
shomeser 14.03.2013 01:32 # 0
у нас ещё встречались товарищи, которые -1 возвращали в качестве указателя
bormand 14.03.2013 05:42 # +3
defecate-plusplus 14.03.2013 10:01 # +2
чтобы делать while (stream >> item) ..., при этом, не конфликтовало с приведением к int
в c++11 заменили на explicit operator bool ()
defecate-plusplus 14.03.2013 07:48 # 0
std::string::npos, например
такое нередко встречается в жизни, когда надо из беззнаковых чисел выбрать специальное
absolut 14.03.2013 09:53 # +1