Publish @Zeux: Еще раз о выстрелах в ногу и STL
Вообще говоря, это вечная тема - сколько надо знать о деталях реализации, насколько можно полагаться на библиотеки итд итп. Тут история уже второго уровня - есть благие намерения и известно, что требуются дополнительные приседания в виде преаллокации массива, но пуля прилетает туда же, куда и обычно
( Read more... )
+1
человек, который это пишет, не понимает как работает vector. делать reserve в цикле почти всегда тупо.
если хотелось улучшить, то можно было сделать reserve один раз на estimated_number_of_shapes * average_numer_of_vertices_per_shape или что-то такое. хотя и тут можно налететь, что если аллокировал меньше, чем надо, то при resize оно удвоится и станет огромным. а если бы просто без reserve вставлял, то доросло бы до гораздо меньшего размера.
Reply
А иначе да, соглашусь, человек который пишет reserve(size() + 24), не знает как реализован vector::reserve в популярных STL. Опять отмечу что с т.з. формальной разницы между reserve(size() + 24) и resize(size() + 24) в скорости быть не обязано - просто так получилось что reserve() exact, а resize() с grow.
Reply
Именно так. Поэтому лучше хорошая дека.
> не знает как реализован vector::reserve в популярных STL
И как работает push_back в любом stl. Возможно он не ожидал квадрата, но зачем было вообще писать reserve? Что он должен был улучшить? Даже если бы он был не exact, то разницы бы не было со второй итерации цикла. Premature optimization как она есть.
Reply
Reply
Reply
Leave a comment