информационная безопасность
без паники и всерьез
 подробно о проектеRambler's Top100
Spanning Tree Protocol: недокументированное применениеВсе любят медСтрашный баг в Windows
BugTraq.Ru
Русский BugTraq
 Анализ криптографических сетевых... 
 Модель надежности двухузлового... 
 Специальные марковские модели надежности... 
 Бэкдор в xz/liblzma, предназначенный... 
 Три миллиона электронных замков... 
 Doom на газонокосилках 
главная обзор 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 02:31  Число просмотров: 967
Автор: kabanchik Статус: Незарегистрированный пользователь
<"чистая" ссылка>
> Voobchem vse tak i est` v Win32 tolko svobodnaia pamit`
> pomechaets`ia chto ona svobodna , a pointers ne nee ni v
> kakie listy ne za sovyvaetsia, i kogda nuzhen kusok pamiati
> prohodiatsia po heap i ichetsia svobodnyi kusok v etoi
> page, esli ne niden to allociruetsia novyi kusok v novoi
> page . . . (upuskaia podrobnosti tak rabotaet heap
> allocation)
ну это понятно. такое уже есть и это не столь интерестно.
Недостаток - имею свободные места - 256Byte, 128 Byte, 64 Byte - разбросанные по разным местам. теперь надо выделить память - 64б . 128б, 256б - поочередно. если беру по первому встречному, то для 256б не остается места, т.к. сначала запрашивается 64б, и сразу встречаю 256 свободного - останеться (256-64)б. для 128 беру из (256-64), для 256 - фиг возмешь. бегать каждый раз по всему дереву искать не первый встречный, а наиболее приближенный - удовольствие очень дорогое. сортировать по убыванию - тоже. но с другой стороны на метод первого встречного не теряю много времени. но по любому поиск-вставка-доступ и прочее, элементов в связанном списке наиболее медленный.

> I ne dumau chto zdes` chto ot mozhno optimizirovat`.
> potomuchto search ne bol`shoii i vedets`ia tolko vnutri
> odnoii page.
можно. задача на самом деле есть, хотя бы из вышеизложенного - сортировка и время. интуитивно оптимальный вариант как то можно связять с бинарным деревом или может еше с чем. вот и пытаюсь выяснить имеет смысл делать со связянными листами, где поиск элемента процедура не быстрая зато алгоритм довольно простой, или искать другой вариант, а может лист - это единственный вариант.
а насчет небольшого поиска - все зависит на сколько часто будешь запрашивать и удалять память. можно так "изуродовать" кучу, что поиск может стать актуальным.

вот еще задача:
имею кучу 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-2024 Dmitry Leonov   Page build time: 0 s   Design: Vadim Derkach