Akina, ну этот случай само собой очевиден, я же написал, что таблица будет своевременно увеличиваться, и я так-же не собираюсь иметь uint32_max значений.
Если таблицу расширять заранее, например когда кол-во имеющихся элементов занимает 75%, то можно ли тогда подобрать такую функцию, которая позволит избежать коллизий вовсе?
По умолчанию у нас есть лишь блок 128B. Запрос на выделение 50 байт, мы делим блок 1 пополам, выдаём блок 2, что делаем с блоком 3? Сохраняем ли его куда-нибудь?
Wataru, в этом случае, при поиске маленького блока, нам придётся перебирать частично занятые большие блоки(в них же может влезть маленький), а это долго.
Так проблема как раз в том, что выдавая блок основываясь на двусвязном списке, нельзя оперативно удалить его "детей" и "родителя" из списков других порядков.
Для примера выше:
3 списка
free_lists[0]: 1
free_lists[1]: 2<->3
free_lists[2]: 4<->5<->6<->7
Выдавая блок 2, нам нужно удалить из списков выше и ниже блоки 1, 4, 5, но это сделать сложно, т.к. они могут находиться там в произвольном порядке, не перебирать же все списки.
Вот как с этой проблемой совладать?
jcmvbkbc, позволю себе спросить ещё вот что: можно ли выравнять адрес до ближайшей к нему степени двойки (в большую сторону)? 1000 -> 1024, 3000 ->4096 и т.д.
то верно ли то, что для прослушивания радио достаточно будет демодулировать частоты от 102.285 МГц до 102.315 МГц(для некой радиостанции на частоте 102.3 МГц)? Без примочек аля стерео конечно.
Судить о том, что будет выполняться быстрее, в современных процессорах, это гиблое дело, ибо всё зависит от конкретной модели, конкретного случая и может даже от цены фьючерсов на титан.
Если таблицу расширять заранее, например когда кол-во имеющихся элементов занимает 75%, то можно ли тогда подобрать такую функцию, которая позволит избежать коллизий вовсе?