Охохо. Это значит, я напортачил в классификации операторов. И «вопрос для гуру» был неверным. Ну ничего, я провел серию тестов и переписал неправильные части. Надеюсь, правильно ))
Выходит, если определяется новый оператор new с параметрами, нет никакой возможности определить ему отдельный delete, всегда будет вызываться стандартный delete (кроме случая исключения в конструкторе)
да в принципе и так ничего не сломается. просто такие new будут брать объекты не из пула, а из хипа, а соответствующий delete будет возвращать обратно в хип.
Да, это серьёзная ошибка, которая может сломать некоторый код.
Я в замешательстве. Если исправлять всё это корректно, нужно будет добавлять в класс PagePool функционал, обрабатывающий нехватку памяти, что усложнит учебный пример, и так уже получивший претензии за излишнюю сложность ))))
Пожалуй, я добавлю коммент в класс. Если кто-то пользуется new(nothrow_t), он знает, как доделать.
Если же не пользуется, у него ничего не сломается, как не сломалось в высоконагруженной программе IRainman-a
Если бы я начал описывать, как построить связный список или зачем нужно выравнивание, то читатели, до которых я хотел донести информацию, плюнули бы на середине и закрыли страницу.
Статья расчитана на тех, кто уже пытался писать свои аллокаторы. Акцент в статье — на перегрузке операторов и синтаксических конструкциях для работы со своими аллокаторами, как с минимальными затратами преобразовать существующую программу.
Тривиальные классы я сначала не хотел приводить, затем засунул под спойлер.
1. Удаление оптимизатором пустого цикла не происходит, тогда время было бы 0. Тем более, в отдельных случаях я достиг времени, как у CLR, так что сравнение честное.
2. Как раз первый пример и устраняет фрагментацию. Объекты разных типов лежат в непересекающихся пулах, а внутри пула фрагментация значения не имеет. Поиск свободного блока — O(1), все блоки в пуле одинаковые, поэтому нет случая, когда много свободного места по мелочи, а взять нечего.
3. Первый пример предусматривает возврат неиспользуемой памяти, смотрите внимательнее. Если алгоритм съест всю память, то значит она вся нужна (выделена)
4. Ну отлично. Проверьте всё же класс BlockAlloc, ведь переделки программы совсем тривиальные (и ещё вернуть надо в состояние до-GC, когда delete не забывали вызывать)
Эх, FastMM… Юзал в дельфи для поиска утечек памяти. Очень удобно — при закрытии приложения каждая утечка описана со stacktrace-ом, где сделано выделение.
В MSVC всё печальнее — только список утечек, без стека, если включать _CrtSetDbgFlag(_CRTDBG_LEAK_CHECK_DF)
если интел выпустит аналогичный продукт (и также без оптимизаций), то зачем переходить?
Если у вас есть идея, как доказать преступный умысел одного конкретного сотрудника, поделитесь
Выходит, если определяется новый оператор new с параметрами, нет никакой возможности определить ему отдельный delete, всегда будет вызываться стандартный delete (кроме случая исключения в конструкторе)
Мы — да. Но следующее поколение уже не сможет.
Я в замешательстве. Если исправлять всё это корректно, нужно будет добавлять в класс PagePool функционал, обрабатывающий нехватку памяти, что усложнит учебный пример, и так уже получивший претензии за излишнюю сложность ))))
Пожалуй, я добавлю коммент в класс. Если кто-то пользуется new(nothrow_t), он знает, как доделать.
Если же не пользуется, у него ничего не сломается, как не сломалось в высоконагруженной программе IRainman-a
Как я его раньше не видел — ума не приложу
Статья расчитана на тех, кто уже пытался писать свои аллокаторы. Акцент в статье — на перегрузке операторов и синтаксических конструкциях для работы со своими аллокаторами, как с минимальными затратами преобразовать существующую программу.
Тривиальные классы я сначала не хотел приводить, затем засунул под спойлер.
очень давно тестил на Celeron D 320, были другие результаты.
2. Как раз первый пример и устраняет фрагментацию. Объекты разных типов лежат в непересекающихся пулах, а внутри пула фрагментация значения не имеет. Поиск свободного блока — O(1), все блоки в пуле одинаковые, поэтому нет случая, когда много свободного места по мелочи, а взять нечего.
3. Первый пример предусматривает возврат неиспользуемой памяти, смотрите внимательнее. Если алгоритм съест всю память, то значит она вся нужна (выделена)
4. Ну отлично. Проверьте всё же класс BlockAlloc, ведь переделки программы совсем тривиальные (и ещё вернуть надо в состояние до-GC, когда delete не забывали вызывать)
В MSVC всё печальнее — только список утечек, без стека, если включать _CrtSetDbgFlag(_CRTDBG_LEAK_CHECK_DF)
Может, кто посоветует leak detectors для MSVC.