информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Spanning Tree Protocol: недокументированное применениеГде водятся OGRыСтрашный баг в Windows
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Phrack #70/0x46 
 Возможно, Facebook наступил на... 
 50 лет электронной почте 
главная обзор RSN блог библиотека закон бред форум dnet о проекте
bugtraq.ru / форум / programming
Имя Пароль
ФОРУМ
все доски
FAQ
IRC
новые сообщения
site updates
guestbook
beginners
sysadmin
programming
operating systems
theory
web building
software
hardware
networking
law
hacking
gadgets
job
dnet
humor
miscellaneous
scrap
регистрация





Легенда:
  новое сообщение
  закрытая нитка
  новое сообщение
  в закрытой нитке
  старое сообщение
  • Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
  • Новичкам также крайне полезно ознакомиться с данным документом.
[C++] Memory Manager - контроль кучи, алгоритм. Что скажете? 16.06.01 16:15  Число просмотров: 778
Автор: Delimiter Статус: Незарегистрированный пользователь
Отредактировано 16.06.01 21:10  Количество правок: 4
<"чистая" ссылка>
> ну это понятно. такое уже есть и это не столь интерестно.
> Недостаток - имею свободные места - 256Byte, 128 Byte, 64
> Byte - разбросанные по разным местам. теперь надо выделить
> память - 64б . 128б, 256б - поочередно. если беру по
> первому встречному, то для 256б не остается места, т.к.
> сначала запрашивается 64б, и сразу встречаю 256 свободного
> - останеться (256-64)б. для 128 беру из (256-64), для 256 -
> фиг возмешь. бегать каждый раз по всему дереву искать не
> первый встречный, а наиболее приближенный - удовольствие
> очень дорогое. сортировать по убыванию - тоже. но с другой
> стороны на метод первого встречного не теряю много времени.
> но по любому поиск-вставка-доступ и прочее, элементов в
> связанном списке наиболее медленный.
>

метод первого встречного - хорошо конечно
( но почему не второго ,третьего...etc) (алгоритм смены лучшего не проблема) пройтись до первого встречного или по всему "массиву"
....я думаю не критично

примерно так
uint lookforsize; // какой размер ищем
uint between; // для хранения разницы
uint nchoise; // индекс выбора
between=sizeofheap; // присваиваем максимальный размер элемента
char *returnvalue //возврашаемый указатель

for(uint i=0;i<number_elements;i++)
{
if(elementisempty(i))
if(lookforsize<getsizeofelement(i))
if((getsizeofelement(i)-lookforsize)<between)
{
nchoise=i;
returnvalue=getpointerofelement(i);
between=getsizeofelement(i)-lookforsize;
}
}
if(nchoise!=numberofelement) // не последний?
{ // расчщщщепляем средний толкайя
for(uint j=numberofelement;j>nchoise;j--)
copyelement(j,j-1); // направление j <- j-1
numberofelement+;
}
copyelement(nchoise+1,nchoise);
setelementpointer(getelementpointer(nchoise)+lookforsize,nchoise+1)
// корректируем pointer^^^
setsizeofelement(lookforsize,choise);
setsizeofelement(getsizeofelement(choise+1)-lookforsize,choise+1);

setbuzy(nchoise); // теперь будет занято
return returnvalue;

один проход only :))

.... процедуру слияние двух рядом лежаших пустых блоков
я бы посоветовал делать во момент освобождения блока
uint totalsize;
setelementasempty(index)
for(uint i=0;i<numberofelment-1;i++)
{
if(elementisempty(i) && elementisempty(i+1))
{
totalsize=getsizeofelement(i)+getsizeofelement(i+1);
for(uint j=i;j<numberofelement-1;j++)
copyelement(j,j+1);
setsizeofelement(totalsize,i);
numberofelement--;
}
}

> можно. задача на самом деле есть, хотя бы из
> вышеизложенного - сортировка и время. интуитивно
> оптимальный вариант как то можно связять с бинарным деревом
> или может еше с чем. вот и пытаюсь выяснить имеет смысл
> делать со связянными листами, где поиск элемента процедура
> не быстрая зато алгоритм довольно простой, или искать
> другой вариант, а может лист - это единственный вариант.
> а насчет небольшого поиска - все зависит на сколько часто
> будешь запрашивать и удалять память. можно так
> "изуродовать" кучу, что поиск может стать актуальным.

я думаю что использовать достижения MS -хорошо, но если у тебя
время-критично, то алгоритмы с указателями дадут тебе 100% превосходство, ведь МS-MFC-лишь продукты от вышеуказанных алгоритмов.....но это только мое мнение :))))

>
> вот еще задача:
> имею кучу 4Kb. по каким то причинам и обстоятельствам у
> меня получается такая картина,- х - это занятый блок,
> размером 64 byte :
>x|x|x|x|.....|x- до 4 Кб, через 1,
> занято-свободно.
> теперь запрос на 256 байт. в итоге у меня 2Кб свободного
> места, а реально вынуждев выделить еще одну кучу. как потом
> собирать "мусор", высвобождать побольше свободного места.
>

даже и не думай решать такую задачу для общего случая :)))))
куча - это не кучка, а если хочешь наплодить кучек..... :))
тогда назови их по другому :)) ира, вася,....
если хочешь научить их свойствам КУЧИ спроси у КУЧИ че она
скажет в аналогичной ситуации :)))

реалокейт - дело не отдельно взятого метода а системы
если какаянидь ОС не умеет это делать, то это надолго:))

но всего скорее я не прав ....:)))
> и это не все проблемя, можно найти много задач - куча штука
> не шуточная :-)))
>
> вот и хочу пообсуждать об этом. может кто сталкивался, или
> есть идеи. принимаются любые идеи, вплоть до того, чтоб
> бросить программинрование :-)))) но все должно быть
> аргументированно.
>
>
> > a zachem eto tebe?
> написать Memory manager :)))
> есть такая задача и ее надо написать.
<programming> Поиск 








Rambler's Top100
Рейтинг@Mail.ru


  Copyright © 2001-2021 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach