Всем привет! У меня задачка появилась: Необходимо подменить стандартный аллокатор памяти allocator<type> на свой в STL. Я кое что накопал по этому поводу, но это не работает, во всяком случае правильно. Возникает ошибка в менеджере памяти, Но этого быть никак не может! Он проверенный и хорошо работает. Поэтому я думаю что не правильно наследовал, хотя все вроде делают так.. Можно было бы перегрузить new, но для меня это не выход, хотя с перегруженным new работает нормально)  



Если кто знает как правильно наследовать аллокатор.. ну или какието другие решения, буду признателен.

SIRIUStar - не когда не наследуйся от STL(разумеется кроме exception)
Алакатор свой вставляешь через шаблон(смотри сигнатуру используемого класса)

SIRIUStar, что за ошибка?

Если Winnie::Alloc(n)  и Winnie::Free(n) заменить на обычные alloc и free работает?

Lycifer, почему нельзя от stl наследоваться?

ибо у них не предусмотрено виртуальных деструкторов
правда слово "никогда" тут некстати, ибо иногда это делать можно


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

Вот пример аллокатора, можно просто заменить Allocate и Free;

SIRIUStar - не когда не наследуйся от STL(разумеется кроме exception)
Алакатор свой вставляешь через шаблон(смотри сигнатуру используемого класса)

Хм, чего не знал того не знал)) тоесть получется, что память забирается, но не освобождается при таком наследовании?

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

это я понимаю.. но думал что от std::allocator наследоваться будет правильней)

Спасибо за примеры)) Да и кстате при замене аллокатора винни на связку malloc/free возникает ошибка Corruption Heap   (страшновато звучит) будем пробовать дальше)

Это сообщение отредактировал(а) SIRIUStar - 24.1.2009, 23:11

SIRIUStar, попробуй использовать мой пример сначала с malloc/free, потом с винни, напиши что будет

SIRIUStar, просто убери из кода

Всем спасибо) вопрос закрыт,  нашел у себя ошибку)
Дело в том, что метод allocate нужно реализовывать так:



Этот момент я упустил, без примеров бы долго тупил))     

Думаю создавать отдельную тему не стоит, поэтому задам вопрос тут 

Существует приложение + плагины выполненные в виде dll/so библиотек, в приложении существует хост-объект, при инициализации библиотек им передается указатель на хост-объект (библы скомпилены с хидером в котором описаны все интерфейсы хоста и других предоставляемых приложением объектов, после получения указателя на хост, плагин от хоста получает указатель на фабрику объектов clsExecutorInterface, а затем регистрирует все доступные в плагине реализации clsExecutor, в дальнейнем, экземпляры зарегеных классов создаются в любом порядке. Строковые параметры в данный момент передаются как char*. Собственно это была преамбула, а теперь вопрос: если я заменю все char*на string (соответственно переписав необходимый и зависимый код), какой аллокатор памяти будет использоваться в экземплярах классов созданных на фабрике? Я думаю, что аллокатор из приложения, а не из библиотек, но все таки, кто может подсказать?

из библиотек, шаблоны инстанциируются во время компиляции
К.О.

не советовал бы использовать std::string (да и другие стл-типы)  для передачи параметров между библиотекой и приложением.

Вот поэтому и решил посоветоваться, т.к. вроде бы и библиотека, но объект создается на фабрике основного приложения, и все параметры передаются/принимаются уже этим объектом. Спасибо за информацию.

Если память выделяется в приложении используется аллокатор приложения, если выделяется в библиотеке используется аллокатор библиотеки и они могут быть абсолютно разными, потому что модули могут быть скомпилированны различными компиляторами с различными настройками или использовать третьесторонние аллокаторы (Heap мэнеджер ОС Windows или такие как tcmalloc, horde и др.). Я думаю понятно что произойдёт если попытаться освободить память одним аллокатором выделенную на самом деле другим аллокатором. Отсюда следует золотое правило: освобождать память там где выделил. 
Если уж придётся передавать данные так что они должны будут освободиться в другом модуле то можно чтоб например приложение или библиотека предоставляла соответствующее API для выделения и освобождения памяти (это довольно общепринятая практика в больших библиотеках/модульных системах). Но динамическая подмена аллокаторов(чтоб использовать например в СТЛе аллокатор предоставляемый приложением) это отдельный изврат да и вообще редко когда осуществимо.

Именно поэтому использовал с самого начала char*, просто точно не знал где выделяется память если объект создается на фабрике основного приложения (как я понял из постов выше, даже если объект создается на фабрике хоста, то память все равно выделяется в длл/со)

Это сообщение отредактировал(а) BasMan - 15.3.2009, 06:42