Добрый день !

Жизнь заставила взяться за нестандартное управление памятью. Проекты стали большие, ввиду активного управления памятью стали какие-то хвосты появляться...

Ввиду того, что я предпочитаю велосипеды собственного изобретения , я разработал вот такой вот класс.

Работать с ним достаточно просто:

Код

#include "pool.h" using namespace AVN::Memory;   // на всяк. случай я все запихнул в собственное пространство имен class A {   int a; public:   void set (const int Val)   { a = Val; }   int get (void) const   { return a; } }; // ... UP<A> ptr;    // UP - указатель на объект типа A. Автоматически уничтожается деструктором SA<A> ar1(10);  // SA - массив, где проверяются пределы в operator[] PA<char> buf(10); // PA - массив, где пределы не проверяются, но зато есть operator char* ptr->set(15); ar1[2].set(13); strcpy (buf, "assad"); A *b; ptr = b;  // автоматическая очистка и создание НОВОГО экземпляра, скопированного из *b ar1.alloc (10); // очистка и распределение

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

Данная схема позволяет переопределить операторы new и delete - пробовал, работает .

"Нестандартность" заключается в следующем: память берется не из "кучи", а распределяется блоками различных размеров. При очистке памяти блок остается, только удаляется метка о том, что он занят. Т. е. удаление происходит очень быстро. Да и распределение, в общем-то, тоже. Таким образом, идеально подходит для случаев, где память "тасуется" - часто удаляется и распределяется.

Всего 5 типов пулов памяти: для объектов 4б, 64б, 256б, 32 Кб и 16 Мб (соответственно, в каждом пуле выделяется 256 блоков размерами 4б, 8б, 256б, 1Кб, 64Кб).

Кто желает попробовать и, возможно, усовершенствовать, пишите.
Добавлено @ 17:26
Да, забыл добавить.

Эта схема дает очень важную возможность для отладки: добавить имя функции и тип данных (присутствует только при #define _DEBUG):

Код

UP<type> var ("function name"); // добавляет имя функции

Еще ряд полезных функций:

Код

size_t UsedMemoryBytes (char Type = 0);                // выделено памяти (байты): вся, 4 Б, 8 Б, 256 Б, 1 КБ, 65 КБ unsigned long UsedMemoryObject (char Type = 0);        // выделено памяти (объекты): вся, 4 Б, 8 Б, 256 Б, 1 КБ, 65 КБ #ifdef _DEBUG void AllocatedObjects (char *str, char Type = 0);    // список объектов (объекты): вся, 4 Б, 8 Б, 256 Б, 1 КБ, 65 КБ. СТРОКА БОЛЬШАЯ !!! #endif    // _DEBUG

Т. е. можно следить за состоянием памяти.

И, в конец концов, самое, на мой взгляд, полезное: можно сделать так:

Код

funct () {   MemoryStack limit; // ... }

Конструктор MemoryStack запоминает текущее состояние: где, какие объекты и сколько. При вызове своего деструктора восстанавливается запомненное состояние. Т. е. автоматическое удаление всего мусора, причем гораздо быстрее вызовов delete. Это удобно при перегруженных new и delete.

Присоединённый файл ( Кол-во скачиваний: 10 )
 pool.zip 5,83 Kb

Хотелось бы сравнения с STL
Вообще, насчет этого

Цитата

При очистке памяти блок остается, только удаляется метка о том, что он занят. Т. е. удаление происходит очень быстро.

Оно вроде так и есть...

Это сообщение отредактировал(а) sergej.z - 9.12.2005, 17:35

Цитата(Neitron @ 9.12.2005, 18:29)

Оно вроде так и есть...

Согласен,память не отчищается,все что в ней хранилось после ее освобождения так и хроанится,только "ни компьютор ни программа про это не знают" и когда надо затирают.

Цитата(nikitao @ 9.12.2005, 16:35)

Согласен,память не отчищается,все что в ней хранилось после ее освобождения так и хроанится,только "ни компьютор ни программа про это не знают" и когда надо затирают.

Но необходимо обращение к системе. Оно очень много ресурсов занимает.

Цитата(sergej @ 9.12.2005, 17:36)

Цитата(nikitao @ 9.12.2005, 16:35) Согласен,память не отчищается,все что в ней хранилось после ее освобождения так и хроанится,только "ни компьютор ни программа про это не знают" и когда надо затирают. Но необходимо обращение к системе. Оно очень много ресурсов занимает.

Отож! Я сделал простенький тест:

программа 1:

Код

for (unsigned long f = 0; f < 10000000; ++f) {   int *q = new int[500];   double *w = new double[50];   w[10] = 0;   q[10] = 0;   delete [] w;   delete [] q; }

и программа 2:

Код

for (unsigned long f = 0; f < 10000000; ++f) {   SA<int> q.alloc (500);   SA<double> w.alloc (50);   w[10] = 0;   q[10] = 0; }

Разница была раз в 10, если не больше! В пользу программы 2, естественно .

Засекал я в Windows XP в Task Manager по времени занятости процессора данной программой. На глаз, но очень даже впечатляет .

Хотя для маленьких объектов разница не столь высока.

Цитата(Neitron @ 9.12.2005, 17:29)

Хотелось бы сравнения с STL

Мне бы тоже .

Я не настолько дружу с STL. Да и вообще, в программировании я использую WinAPI без MFC и C++ без STL. Подсмотрел я это у программистов из Aldec Inc. - я у них стажировался пару месяцев. Они там от MFC отказались из-за того, что оно очень тормозило их систему (очен мощный копмилятор и симулятор FPGA, CPLD с VHDL, Verilog). Ну а с STL там тоже было весело - в версии от Microsoft оно глючит, поэтому использовали версию от SGI, если не ошибаюсь. Но там тоже были глюки. Поэтому я решил использовать СВОЕ.

Ну и потом: насколько я знаю, STL не оптимален по своей природе, т. е. на ассемблере он выглядит громоздко. Впрочем, судить не берусь - код с ним не компилировал, не изучал результат.

Цитата(Guest @ 9.12.2005, 18:47)

Ну и потом: насколько я знаю, STL не оптимален по своей природе, т. е. на ассемблере он выглядит громоздко. Впрочем, судить не берусь - код с ним не компилировал, не изучал результат.

Каждый контейнер STL чательно разрабатывался и дорабатывался.Так что там на 99% наилучший возможный код.Контейнеры STL универсально и за эту универсальность приходится платить,но цена эта 1.Довольно низка 2.В одиночку,торопясь,вряд ли лучше получится.

Цитата(nikitao @ 9.12.2005, 17:52)

Цитата(Guest @ 9.12.2005, 18:47) Ну и потом: насколько я знаю, STL не оптимален по своей природе, т. е. на ассемблере он выглядит громоздко. Впрочем, судить не берусь - код с ним не компилировал, не изучал результат. Каждый контейнер STL чательно разрабатывался и дорабатывался.Так что там на 99% наилучший возможный код.Контейнеры STL универсально и за эту универсальность приходится платить,но цена эта 1.Довольно низка 2.В одиночку,торопясь,вряд ли лучше получится.

Согласен.

Причём STL к менеджеру памяти? Разве там память не через new выделяется?

Цитата(sergej @ 9.12.2005, 15:01)

Причём STL к менеджеру памяти? Разве там память не через new выделяется?

Действительно, вопрос к знатокам: в STL реализован свой алгоритм управления памяти и сборки мусора? Если нет, то никто не мешает переопределить глобально new и delete и, используя STL, там использовать оный менеджер!

Цитата(sergej @ 9.12.2005, 20:01)

Причём STL к менеджеру памяти? Разве там память не через new выделяется?

Управление памятью в STL параметризуется аллокаторами.

Цитата(A @ 9.12.2005, 20:26)

Если нет, то никто не мешает переопределить глобально new и delete и, используя STL, там использовать оный менеджер!

Глобальное переопределение new/delete - это плохой тон, можно нарваться на крупные проблемы. Конкретно для использования собственного алгоритма распределения памяти в STL лучше использовать аллокаторы. Посмотрите на Boehm GC, как там это организовано.

обнаружив в свое время в stl некое подобие смарт поинтера auto_ptr<>, я, было, обрадовался. но когда оказалось, что его нельзя использовать в тех же stl коллекциях, интерес мой к нему поостыл.

немножко в офф: из велосипедов собственного сочинения некогда сочинил собственный строковый класс. возникла задачка по созданию строк очень большой длины (десятки мегабайт) путем конкатенации маленькими кусочками (в несколько байт). std::string давал очень плохой перформанс. пришлось сочинить свою строку, которая аллокировала память более агрессивно, но зато намного более эффективно.

Цитата(Void @ 9.12.2005, 16:41)

Глобальное переопределение new/delete - это плохой тон, можно нарваться на крупные проблемы.

Как я вижу, моя библиотека дает выигрыш по производительности по сравнению с версией от Microsoft Visual C++ 7. Рискну попробовать перегрузить и посмотрю, как оно будет. Я сейчас веду два крупных проекта - две большие программы с активной работой с памятью. Там сразу будут видны хвосты и рога

Цитата(blackofe @ 9.12.2005, 16:55)

немножко в офф: из велосипедов собственного сочинения некогда сочинил собственный строковый класс.

Я тоже начал с такого же "велосипеда" .

Продолжаю преобразование своей библиотеки - делаю более универсальной и качественной. Как вижу, библиотека широкую общественность не заинтересовала . Если кому понадобится последняя версия - lexandre_n AT mail.ru.

М	Я вставил AT против спаммеров... sergej.z

Это сообщение отредактировал(а) sergej.z - 12.12.2005, 13:57

Мои 5 копеек.
Во-первых перед выставлением кода на достояние публики следовало проверить работу на нескольких компиляторах.
Два моих гнуса ругались. Комо ругался.
Причём они ругались на код в хедере. Гнусы схавали содержимое pool.cpp без единой
Во-вторых

Код

struct Debugger {         Debugger(){std::cout << "Debugger";};         ~Debugger(){std::cout << "~Debugger";}; }; int main() {    UP<Debugger> deb;         std::cout << "hello" << std::endl; }

при запуске произошел страшный упс - программа вывела на экран две строки. При чём если "hello" была предсказуемой, то "Segmentation fault" было явно не тем, что я ожидал.
Я заменил UP<Debugger> deb на UP<Debugger> deb=0; и получил новое сообщение об ошибке в гнусе 3 (четвертый ругался еще страшнее):

Цитата

pool.h: In member function `const T* AVN::Memory::UP<T>::ptr() const [with T =   Debugger]': pool.h:172:  instantiated from `AVN::Memory::UP<T>::UP(const AVN::Memory::UP<T>&, const char*) [with T = Debugger]' main.cpp:15:  instantiated from here pool.h:189: error: passing `const AVN::Memory::UP<Debugger>' as `this' argument   of `void* AVN::Memory::UPVoid::Ptr()' discards qualifiers

Попробовал сделать UP<Debugger> deb(new Debugger); и узнал что

Цитата

main.cpp: In function `int main()': main.cpp:15: error: no matching function for call to `AVN::Memory::UP<Debugger>   ::UP(Debugger*)' pool.h:172: error: candidates are: AVN::Memory::UP<T>::UP(const   AVN::Memory::UP<T>&, const char*) [with T = Debugger] pool.h:171: error:                AVN::Memory::UP<T>::UP(const char*) [with T   = Debugger]

Пробовал скомпилить

Код

struct Debugger {         Debugger(){std::cout << "Debugger" << std::endl;};         ~Debugger(){std::cout << "~Debugger" << std::endl;};         void hello(){std::cout << "Debugger::hello" << std::endl; } }; int main() {         UP<Debugger> deb;         deb->hello();         std::cout << "hello" << std::endl; }

и получил

Цитата

Debugger::hello hello Segmentation fault

Вместо ожидаемого

Цитата

Debuger Debugger::hello hello ~Debuger

Мой моск устал думать в этом направлении.

например, Арт Фридман считает, что самописный аллокатор - идея опасная и, чаще всего, неоправданная.