Универсальный менеджер памяти. (комментарии)

Универсальный менеджер памяти. (комментарии)

Это сообщение сгенерировано автоматически.

Может кто-нибудь что-нибудь-скажет? +/- ы? оценит?

Nekrom@NT
Обязательно надо переопределить все 3-и new и все 3 delete, иначе будут траблы при определённых стеченихя=)

>Может кто-нибудь что-нибудь-скажет? +/- ы? оценит?
А где собсно эти самые плюсы и минусы? в статье их нету, хотя автор обязан был их написать

И еще не понравилась привязка к своей либе, на кой? или это раскрутка своей либы? ;)

>Обязательно надо переопределить все 3-и new и все 3 delete, иначе будут траблы при определённых стеченихя=)
ясное дело, это в любой бумажке по плюсам написано. там был класс с многоточиями т.е. показана примерное использование.
>И еще не понравилась привязка к своей либе, на кой? или это раскрутка своей либы? ;)
Это штобы небыло тупого копипаста. Пусть прочитавший сам повторит, оно полезно для закрепления. Кроме-того исходники в стаье почти целиком из либы, мне было не до переправки.
>+/-
я имел ввиду плюсы минусы статьи а не менеджера.
>+/-
менеджера обязательно допишу.

Почему-то мне кажется, что стандартный менеджер памяти на стресс тесте покажет результаты куда лучше твоего в отношении "время/объем не эффект. исп. памяти":)
Зачем нужен поиск по map'у каждый раз?
Использование пулов для каких-то часто созд./удал. объектов должно быть явным, а не универсальным через менеджер памяти, в ост. же случаях достаточно new.

>Почему-то мне кажется, что стандартный менеджер памяти на стресс тесте покажет результаты куда лучше твоего в отношении "время/>объем не эффект. исп. памяти":)
Когда кажется надо:
а) креститься
б) проверять
На моей машине он быстрее.
Поиск по мапу быстрее, чем выделение куска нужного размера из фрагментированной памяти.
Поиском по мапу не брезгуют в GameProgrammingGems ПЕРВОМ томе, тогда процессоры были куда медленнее!

>Использование пулов для каких-то часто созд./удал. объектов должно быть явным
Ты про инкуапсуляцию слышал?

Nekrom@NT
а вместо map'a  hash_map юзать не пробовал? мож еще быстрей буит?

ЗЫ: жду описания +\- менеджера :)

Или если тебе совсем горит, то возможен такой вот импрувмент:
1) Делаем Managed шаблонным, т.е. при наследовании пишем так:

class Foo: public Managed<Foo> {};

2) заводим в нём статическую переменную-итератор.
3) однажды найдя по мапу позицию для размера объекта - сохраняем её.
4) юзаем позийию вместо поиска по мапу
5) радуемся.

eHomo
1) в конец статьи погляди
2) с хеш мапоп пожалуй да + см. предыдущий пост

Nekrom@NT
>На моей машине он быстрее.
я говорил про разумный баланс между скоростью и занимаемой памятью.

>Поиск по мапу быстрее, чем выделение куска нужного размера из фрагментированной памяти.
(кстати ни мап, ни хеш мап тут не  обязательны, пойдет обычный массив c binary search)
Да, быстрее, а какой в этом смысл? Ты собираешься тысячи раз в секунду использовать new?

>Ты про инкуапсуляцию слышал?
Всё должно быть в меру, и если у меня есть объекты для которых нужно чень много алокаций, те это специфический объекты, то я ни в коем случае не буду пользоваться универсальным способом выделения памяти типа new для каждого из них, а буду выделять и удалять память явно ручками из пула, просто и надежно.
Скорее всего это будет вообще структура, и боже упаси еще наследовать её от кого-то.

>я говорил про разумный баланс между скоростью и занимаемой памятью.
Баланс нормальный. Если совсем тяжко и большие пространствва остаются, то можно запоминать и в список св. памяти пихать, если слишком большое, то по степеням двойки дробить. Ешё можно прицепить "рейтинг" к каждой кучки св. памяти, тогда разбивать на наиболее "популярные" размеры.
>(кстати ни мап, ни хеш мап тут не обязательны, пойдет обычный массив c binary search)
зачем писать нечто своё не больно эффективное, когда есть STL, он по определению хай перфоманс, али вы, батенька, старовер?
>Да, быстрее, а какой в этом смысл? Ты собираешься тысячи раз в секунду использовать new?
Во время загрузки уровня почему бы нет, и я насиделся с кофе ожидая загрузки дарк мессайа, если мой двиг будет так долго грузить, йа павешусь при отладке!
>Всё должно быть в меру, и если у меня есть объекты для которых нужно чень много алокаций, те это специфический объекты, то я ни в коем случае >не буду пользоваться универсальным способом выделения памяти типа new для каждого из них, а буду выделять и удалять память явно ручками из >пула, просто и надежно.
И тем самым, при изменениях в архитектуре, тебе могёт потребоваться што-нибудь переписать, а там 5 разных специфик пулов, каждый под своё, и всем поменять что-ндь нужно, например ты дополнительный уровень абстракции ввёл, в итоге тип указателёй поменялся.
>Скорее всего это будет вообще структура, и боже упаси еще наследовать её от кого-то.
Ну у меня тоже, на самом-то деле наследования нет, у меня память выделяет менеджер ресурсов(нагло клянчит у менеджера памяти), а объект в неё создаёт объект класса, который знает што именно создавать.

И вообще, я вижу, мы бодаемся, не вокруг моей реализации или статьи, а тебе вообще не мила идея универсального менеджера памяти, мол некошерно.

И в чем преимущество, скажем, перед dlmalloc?