Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
Форум программистов > C/C++: Общие вопросы > Аллокатор памяти и STL |
Автор: SIRIUStar 23.1.2009, 00:13 | ||
Всем привет! У меня задачка появилась: Необходимо подменить стандартный аллокатор памяти allocator<type> на свой в STL. Я кое что накопал по этому поводу, но это не работает, во всяком случае правильно. Возникает ошибка в менеджере памяти, Но этого быть никак не может! Он проверенный и хорошо работает. Поэтому я думаю что не правильно наследовал, хотя все вроде делают так.. Можно было бы перегрузить new, но для меня это не выход, хотя с перегруженным new работает нормально) ![]()
Если кто знает как правильно наследовать аллокатор.. ну или какието другие решения, буду признателен. |
Автор: Lycifer 23.1.2009, 15:07 |
SIRIUStar - не когда не наследуйся от STL(разумеется кроме exception) Алакатор свой вставляешь через шаблон(смотри сигнатуру используемого класса) |
Автор: georain 23.1.2009, 18:46 |
SIRIUStar, что за ошибка? Если Winnie::Alloc(n) и Winnie::Free(n) заменить на обычные alloc и free работает? Lycifer, почему нельзя от stl наследоваться? |
Автор: Alek86 23.1.2009, 18:56 |
ибо у них не предусмотрено виртуальных деструкторов правда слово "никогда" тут некстати, ибо иногда это делать можно SIRIUStar, для подстановки аллокатора в экземпляр шаблона не обязательно наследовать - главное, чтоб в твоем классе были нужные функции. |
Автор: georain 23.1.2009, 19:22 | ||
Вот пример аллокатора, можно просто заменить Allocate и Free;
|
Автор: SIRIUStar 24.1.2009, 23:11 |
SIRIUStar - не когда не наследуйся от STL(разумеется кроме exception) Алакатор свой вставляешь через шаблон(смотри сигнатуру используемого класса) Хм, чего не знал того не знал)) тоесть получется, что память забирается, но не освобождается при таком наследовании? SIRIUStar, для подстановки аллокатора в экземпляр шаблона не обязательно наследовать - главное, чтоб в твоем классе были нужные функции. это я понимаю.. но думал что от std::allocator наследоваться будет правильней) Спасибо за примеры)) Да и кстате при замене аллокатора винни на связку malloc/free возникает ошибка Corruption Heap ![]() |
Автор: georain 25.1.2009, 01:59 |
SIRIUStar, попробуй использовать мой пример сначала с malloc/free, потом с винни, напиши что будет |
Автор: Lazin 25.1.2009, 02:13 | ||
SIRIUStar, просто убери из кода
|
Автор: SIRIUStar 26.1.2009, 17:10 | ||
Всем спасибо) вопрос закрыт, нашел у себя ошибку) Дело в том, что метод allocate нужно реализовывать так:
Этот момент я упустил, без примеров бы долго тупил)) ![]() ![]() |
Автор: BasMan 14.3.2009, 20:17 |
Думаю создавать отдельную тему не стоит, поэтому задам вопрос тут ![]() Существует приложение + плагины выполненные в виде dll/so библиотек, в приложении существует хост-объект, при инициализации библиотек им передается указатель на хост-объект (библы скомпилены с хидером в котором описаны все интерфейсы хоста и других предоставляемых приложением объектов, после получения указателя на хост, плагин от хоста получает указатель на фабрику объектов clsExecutorInterface, а затем регистрирует все доступные в плагине реализации clsExecutor, в дальнейнем, экземпляры зарегеных классов создаются в любом порядке. Строковые параметры в данный момент передаются как char*. Собственно это была преамбула, а теперь вопрос: если я заменю все char*на string (соответственно переписав необходимый и зависимый код), какой аллокатор памяти будет использоваться в экземплярах классов созданных на фабрике? Я думаю, что аллокатор из приложения, а не из библиотек, но все таки, кто может подсказать? |
Автор: Lazin 14.3.2009, 20:25 |
из библиотек, шаблоны инстанциируются во время компиляции К.О. |
Автор: mes 14.3.2009, 20:25 |
не советовал бы использовать std::string (да и другие стл-типы) для передачи параметров между библиотекой и приложением. |
Автор: BasMan 14.3.2009, 20:31 |
Вот поэтому и решил посоветоваться, т.к. вроде бы и библиотека, но объект создается на фабрике основного приложения, и все параметры передаются/принимаются уже этим объектом. Спасибо за информацию. |
Автор: sparn 15.3.2009, 02:16 |
Если память выделяется в приложении используется аллокатор приложения, если выделяется в библиотеке используется аллокатор библиотеки и они могут быть абсолютно разными, потому что модули могут быть скомпилированны различными компиляторами с различными настройками или использовать третьесторонние аллокаторы (Heap мэнеджер ОС Windows или такие как tcmalloc, horde и др.). Я думаю понятно что произойдёт если попытаться освободить память одним аллокатором выделенную на самом деле другим аллокатором. Отсюда следует золотое правило: освобождать память там где выделил. Если уж придётся передавать данные так что они должны будут освободиться в другом модуле то можно чтоб например приложение или библиотека предоставляла соответствующее API для выделения и освобождения памяти (это довольно общепринятая практика в больших библиотеках/модульных системах). Но динамическая подмена аллокаторов(чтоб использовать например в СТЛе аллокатор предоставляемый приложением) это отдельный изврат да и вообще редко когда осуществимо. |
Автор: BasMan 15.3.2009, 06:40 |
Именно поэтому использовал с самого начала char*, просто точно не знал где выделяется память если объект создается на фабрике основного приложения (как я понял из постов выше, даже если объект создается на фабрике хоста, то память все равно выделяется в длл/со) |