- 1
chunksLst.erase(++it1);-
C++ / Говнокод #16172
+1
Запостил:
laMer007,
16 Июня 2014
Говнокод: по колено в коде.
Нашли или выдавили из себя код, который нельзя назвать нормальным, на который без улыбки не взглянешь? Не торопитесь его удалять или рефакторить, — запостите его на говнокод.ру, посмеёмся вместе!
© 2008-2024 «Говнокод.ру»
Обратная связь | Лицензионное соглашение | 
Follow us!
Follow us!
самое поганое то что как STL написана, добавить итераторы с проверками (которые можно было бы активировать каким дефайном) в принципе уже невозможно. (ок, возможно, но это такая куча неблагодарной работы, что равносильно переписыванию несколько раз STL с нуля.)
v4 -> v6
ln(-1), возможно будет понятней
в плюсах?
Ну в жабе list это все-таки массив, а не список. Так что там этот код не столько тормозит, сколько не все элементы удаляет :)
P.S. Бесит вот эта разница в терминологии - где-то list это список с произвольной реализацией, к которому можно обращаться по индексу (привет жабе), где-то это явно массив (привет питону), а где-то - именно связный список (привет крестам).
наверное, именно поэтому на странице в педивикии (и русской, и английской) для List красуется рисунок, изображающий связный список - потому что большинство представляет его как массив, ага
и большинству, конечно, известно, что к абстрактному типу данных List не накладываются требования рандомного доступа - лишь последовательного, но их не смущает это противоречие
----
путаница в терминологии возникла именно из-за плохого проектирования дельфиней библиотеки
что мешало им сделать TArray? и как называется связный список в библиотеке? в дельфи же есть в поставке связный список?
Но зачем? Тем, для кого, список это массив, связанный список никак не поможет.
В жабе накладывается.
http://docs.oracle.com/javase/7/docs/api/java/util/List.html#get%28int%29
get(idx) можно и за O(N) выполнить последовательно
> In data structures, direct access implies the ability to access any entry in a list in constant (independent of its position in the list and of list's size, i.e. O(1)) time.
Ага, а теперь удали элемент из середины.
Вы изобретаете новый тип данных?
Сдвинул ячейки, обновил длину. Стандартный подход.
За O(1)? :)
> Стандартный подход.
Я знаю. Но этот подход меняет только константу перед O(n). Неплохо меняет, если структуры большие. Но сложность, увы, не понижает. Ну разве что кроме случая, когда ты удаляешь из списка пачку элементов, а затем один раз перестраиваешь индекс.
Вам "шашечки" или ехать? :)
Мне чтобы таксист не обсчитывал. А кое-кто тут выше написал, что это будет заебись-O(1)-лист :)
на доступ к элементам - да.
http://docs.oracle.com/javase/7/docs/api/java/util/RandomAccess.html
И где я это утверждал?
Википедия в точности подтверждает мою точку зрения - первым идет определение как абстрактной структуры данных. Соответственно говорить о том что, к примеру, хранить в списке нехорошо т.к. будет оверхед по памяти - крестодеформация. Или например считать что число элементов в векторе может изменяться - ну кто мешал им назвать его array?
я неспроста его не нашёл - его тупо нет?
Да и память же не освободится сама по себе, если указатель на нее засунуть в variant и этот variant умрет?
Variant может содержать данные любого типа, за исключением структурных типов и указателей
Да ладно.
Традиционный 32-битный дельфиний БДСМ:
сомнительное удовольствие
Например для малых объёмов данных с небольшими элементами - это вектор. Для такого же объёма данных, но с большими элементами - это вектор указателей на элементы. Ну а дальше уже свзанный лист понятное дело.
А где-то он ленивый и похож на итератор.
Напоминает:
Это stride через 1.
В жабе, крестах и шарпе - точно есть. Да вроде и в остальных был.
> списками, содержащими ссылки на объекты
А с этим в языках, отличных от делфи, давно научились бороться - в крестах RAII, в жабе и шарпе - сборщик мусора. Вот у меня есть небольшой заброшенный проектик на крестах - в нем на 100(!) классов одно рукопашное освобождение памяти, да и то сдуру и от лени, и легко убирается.
ты из какого года пишешь? из 97?
Что мне тебе на это ответить?
Ты мутируешь в царя
меня терзают смутное сомнение, что ты знаешь только 2 языка
Я тоже правлю комменты. И ты правь комменты.
стих вам на ночь
Пуста флудильня, гаснут свечи
Уснули тролли под мостом
И с кофе самка человечья
Тоскливо думает о Нём
Свирепой мамкой погоняем
Уходит юный падаван
Хотя в душе, мы точно знаем,
Желает грабить корован
Прекрасный рыцарь интернета
Натружено шлифует меч
Созданья тьмы, созданья света
Вновь разошлись до новых сечь
Но завтра тут наступит битва
И снова рак пойдет на мид
Окамма отвергая бритву
Здесь будет гарцевать джигит
Воскреснет ненависти слово
Во имя преданной любви
Ну а пока лишь сонный модер
Банхаммер чистит от крови
Или применять цитирование.
Как-то раз я попался на это :)
Прикольная структура данных, кстати. Чувствую себя царем ;(
Но зачем? Неужели такой жесткий дефицит пямяти был?
По талонам тогда еще выдавали.
В делфи никогда не хотелось повесить на один ивент два разных обработчика? Ну или пристегнуть к обработчику некий контекст, например значение переменной вместо упихивания этого контекста в свойство tag или как там его у вас.
> stringBUILDER
Не хочешь - не юзай. Можешь просто складывать строки. СтроительВеревок нужен исключительно ради производительности (и неплохо повышает ее, если тебе надо 100500 строк поклеить).
Просто иногда хотелось навесить на элемент управления некое "поведение" (т.е. набор реакций на ивенты) и при этом лениво было его сабклассить (в делфи же нужно было либо регать свой класс как компонент (что довольно противно, особенно в отладке), либо создавать инстансы врукопашную в OnCreate формы...). Если можно навесить только один обработчик - так не получится.