Для собственного менеджера памяти обычно переписывают new() и delete(), с этим вроде все опнятно.
Но вот как в такой ситуации поступают с аллокаторами контейнеров STL, вроде как они должны самостоятельно отвечать за распределение памяти минуя операции new() и delete(), если правильно понял.
В такой ситуации, как можно переопределить аллокаторы, чтобы заставить их обращаться к собственному менеджеру памяти.
Хотелось бы универсальное решение, не привязанное скажем к STLPort или другой реализации, если такое вообще существует.

Заранее спасибо за ответ.

Здравствуйте, Tujh, Вы писали:

T>Для собственного менеджера памяти обычно переписывают new() и delete(), с этим вроде все опнятно.
T>Но вот как в такой ситуации поступают с аллокаторами контейнеров STL, вроде как они должны самостоятельно отвечать за распределение памяти минуя операции new() и delete(), если правильно понял.
T>В такой ситуации, как можно переопределить аллокаторы, чтобы заставить их обращаться к собственному менеджеру памяти.
T>Хотелось бы универсальное решение, не привязанное скажем к STLPort или другой реализации, если такое вообще существует.

T>Заранее спасибо за ответ.

Посмотри здесь

Автор: dupamid
Дата: 20.04.07

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Tujh, Вы писали:

T>>Для собственного менеджера памяти обычно переписывают new() и delete(), с этим вроде все опнятно.
T>>Но вот как в такой ситуации поступают с аллокаторами контейнеров STL, вроде как они должны самостоятельно отвечать за распределение памяти минуя операции new() и delete(), если правильно понял.
T>>В такой ситуации, как можно переопределить аллокаторы, чтобы заставить их обращаться к собственному менеджеру памяти.
T>>Хотелось бы универсальное решение, не привязанное скажем к STLPort или другой реализации, если такое вообще существует.

T>>Заранее спасибо за ответ.

А>Посмотри здесь

Автор: dupamid
Дата: 20.04.07

Так парень про аллокаторы интересовался, а Вы про итераторы привели ссылки.

Здравствуйте, Tujh, Вы писали:

T>Для собственного менеджера памяти обычно переписывают new() и delete(), с этим вроде все опнятно.
T>Но вот как в такой ситуации поступают с аллокаторами контейнеров STL, вроде как они должны самостоятельно отвечать за распределение памяти минуя операции new() и delete(), если правильно понял.
T>В такой ситуации, как можно переопределить аллокаторы, чтобы заставить их обращаться к собственному менеджеру памяти.

сделав свой аллокатор (а не переопределив чтото там) инстанциируешь все что тебе хочется (контейнеры STL) указывая его в том месте где шаблон требует аллокатора -- в чем проблема то?

class my_mega_allocator;
// ...
std::vector<some, my_mega_allocator> v;

typedef std::basic_string<char, std::char_traits<char>, my_mega_allocator> my_string;
my_string str;
// & etc

главное чтоб интерфейс твоего аллокатора соответствовал требованиям стандарта
проблемы ты огребешь если твой аллокатор окажеца без конструктора по умолчанию (как вот у меня было недавна) %) -- и соответственна все что ты им наинстанциируешь тоже
проблема даже не в создании контейнеров -- все они имеют конструкторы принимающие экземпляр аллокатора
а в том что много алгоритмов (в основном в boost'e) написаны в расчете на то что стринги к примеру дефолтно конструктабелны, что в данном случае буит не так ;(( -- вот тут то и начнуца запары...

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

T>Заранее спасибо за ответ.

Здравствуйте, Tujh, Вы писали:

T>Для собственного менеджера памяти обычно переписывают new() и delete(), с этим вроде все опнятно.
T>Но вот как в такой ситуации поступают с аллокаторами контейнеров STL, вроде как они должны самостоятельно отвечать за распределение памяти минуя операции new() и delete(), если правильно понял.
T>В такой ситуации, как можно переопределить аллокаторы, чтобы заставить их обращаться к собственному менеджеру памяти.
T>Хотелось бы универсальное решение, не привязанное скажем к STLPort или другой реализации, если такое вообще существует.

T>Заранее спасибо за ответ.

Посмотри здесь

Автор: _Winnie
Дата: 08.11.04

или

Посмотри здесь

Автор: _Winnie
Дата: 01.07.05

;

Здравствуйте, Tujh, Вы писали:

T>Для собственного менеджера памяти обычно переписывают new() и delete(), с этим вроде все опнятно.
T>Хотелось бы универсальное решение, не привязанное скажем к STLPort или другой реализации, если такое вообще существует.


Если ты хочешь перекрыть глобальные new и delete, то как бы нет проблем. STL тоже перейдёт на твой мэнеджер.
А если для какого-то конкретного объекта, и при этом в STL-контейнерах захочешь, чтобы эти объекты аллокировались так же, то определи свой аллокатор...