Легенда:
новое сообщение
закрытая нитка
новое сообщение
в закрытой нитке
старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
2 all - delimiter, sandy. поправки !!! 17.06.01 04:52 Число просмотров: 916
Автор: kabanchik Статус: Незарегистрированный пользователь
|
Народ,
с самого начала ЗАБУДЬТЕ про какую либо ОС, будь это Вин, *НИХ, или хрен ..... не связывайте это ни с каким ОС, забудьте про какой либо системный сборщик мусоров, налогов, рекет и прочее явление. Нет никакого виртуального поинтера - это тоже не волнует. так же не волнует как запрашивать память у системы. волнует ЛИШЬ котроль памяти, который я УЖЕ имею у себя.
речь идет о сугубо "ЛИЧНОМ" манагере.
вся суть такая - система выделяет память - на это уходит время. я хочу выделить БОЛЬШОЙ кусок память, чтобы каждый раз не запрашивать у системы по 20-30 байт или 1Кб. и "МНЕ" надо контолировать память - и только "МНЕ", а не системе. Надо котролировать от выделения блоков, до мемори ликов. Заметьте, вынужден повториться, это не Вин, это тем более не МФС, это не *НИХ, это не МАК и пр. Согласитесь, в такой задаче, ОС обсалютно не имеет значения.
2 Delimiter и 2 + :
насчет связанных листов понятно - как не крути, вынужден идти методом "первого встречного". потому как на сортинг и на поиск теряю много времени.
как соединять куски в листе и как проверки делать - это тоже понятно, более того часть кода уже реализована и работает. но не знаю, а может пока не знаю, можно ли там что либо оптимизировать. это потом будет видно.
2 Sandy:
Node-ы в листе в ТАКОЙ ситуации создаются не через
Node* pNode = new Node,
а из того куска памяти, который я уже имею - в pHeap - е, создаю вот так
Node* pNode = new(pHeap)Node; - этот оператор не выделяет новую память, а в имеющейся памяти делает иничиализацию, т.е. просто вызываю конструктор на прямую.
когда говорил о запрете new - имелл ввиду new(size_t nSize), а не new(size_t, void* ptr).
насчет сборки мусора. у меня была некоторая идея, но не знаю на сколько она оправдана.
код вообще то не я сам пишу. но у автора (конкретно cb) была хорошая идея - иметь 2 типа кучи - Спец Куча и Общая Куча. в спец куче, естественно спец объекты, которые не часто и не много создаются, а некоторые из них создаются и лежат до конца. общая куча - это тоже понятна, и она наиболее проблематична!!!
мое предложение было такое :
есть Общая1 и вместе с ним создается Общая2, как олько Общая1 полностью или частично заполняеться, то она перестает выделять память. вместо нее действует Общая2, чтобы по ходу Общая1 частично или полностью освобождалась. после чего "останавливаеться" Общая2 и снова в ход пускается Общая1. и т.д.
т.е. всегда иметь под рукой "временную" кучу, которая и поможет как то вычистить другие рабочие кучи. получается как бы данные кочуют из одной кучи в другую. я не утверждаю, что метод самый лучший, и наиболее оптимальный - это просто идея и думаю есть какой то смысл.
но опять таки -
неужели нет ничего быстрее, чем связаный лист для контроля блоков?
а может с ним иметь еще какой нить другой дополнительный объект?
давайте попробуем оставить связаный лист в покое и попробуем поговорить о других, тоже не маловажных объектах. не забывайте есть vector, map, hash table, binary tree, etc - не объекты реализованные STL или MFC, а прсто их понятие. но мне ща в голову не лезет как и каким образом можно что либо из этого использовать. т.е. "как" понятно, но "каким образом" - не знаю.
|
|
|