Здравствуйте, Глеб Алексеев, Вы писали:

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

B>>[offtop]
B>>Интересно, если в программировании проблемы, которые нельзя свести к оберонам
B>>[/offtop]
ГА>Есть, но они уже 70 лет успешно решаются на Лиспе и Хаскеле .

Ну, как решите приходите. Спарим ваши Лиспы и Хаскели с Обероном. Получится, наверное, Хлиберон. Или Обелисхк.

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

Д>если хорошенько подумать, то подавляющее большинство объектов имеет небольшое время жизни — в одной функции выделили, в другой поюзали и удалили

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

Это я вот к чему. Сначала можно найти книжки для начинающих, где делается так:

int main()
{
  float * a = new float[200];
  ///
}

А потом на ровном месте появляются проблемы с фрагментицией кучи

Статический анализ — хорошо, но иногда мы сами в силах немного помочь

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

GN>Статический анализ — хорошо, но иногда мы сами в силах немного помочь

если тебе нравится этим заниматься, то никто не запрещает
а я предпочитаю, чтобы рутиной за меня занимался компилятор и рантайм

Здравствуйте, Дарней,

GN>>Статический анализ — хорошо, но иногда мы сами в силах немного помочь

Д>если тебе нравится этим заниматься, то никто не запрещает
Д>а я предпочитаю, чтобы рутиной за меня занимался компилятор и рантайм

Я тоже ленивый не хочется лишний раз без повода писать new. Оно ведь может и исключение кинуть. Шутка. ИМХО такие вещи не являются рутиной — делаются на автомате, как расстановка скобочек. Зато могут сделать код более простым для чтения. Я вот до сих пор не могу понять, что хотел сказать автор кода, который я приводил в предыдущем посте

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

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

WH>Меня давно интересует вопрос: зачем вобще нужен realloc? Сколько пишу программы мне realloc ни разу не понадобился.

>Меня давно интересует вопрос: зачем вобще нужен realloc? Сколько пишу программы мне realloc ни разу не понадобился.
Да ну?
Ты ни разу не делал vector.push_back? И тебя удовлетворяет

1) создать массив побольше
2) скопировать туда старый массив
3) прибить старый массив

ну тогда realloc тебе действительно не нужен.

Я имею в виду не конкретную реализацию realloc в MSVC через виндовый HeapReAlloc, а как философию.

Чорный пеар.

Winnie :: Alloc

Вот уже полгода успешно работает в этом проекте (пока не оконченом) + ещё у меня куча благодарственных писем от других пользователей (вроде "у нас скорость сервера выросла на 12%, спасибо большое").

Работает именно через набор пулов блоков фиксированного размера

В Heavy Duty проведена дополнительная оптимизация — на каждый поток свой менеджер памяти, время не тратится даже на синхронизацию.

_Winnie wrote:

> Ты ни разу не делал vector.push_back? И тебя удовлетворяет
>
>1) создать массив побольше
>2) скопировать туда старый массив
>3) прибить старый массив
>
> ну тогда realloc тебе действительно не нужен.
> Я имею в виду не конкретную реализацию realloc в MSVC через виндовый
> HeapReAlloc, а как философию.

Вообще, realloc не подходит для вектора по очень простой причине — в
результате realloc'а может измениться расположение данных в памяти, а
это нельзя делать для С++ных объектов.

Нужна другая функция, которая должна пытаться увеличить размер блока, но
в случае неудачи возвращать NULL, а не делать автоматическое выделение и
перемещение. В MSVC для этого есть нестандартная функция _mgrow.

ЗЫ: в моей bycicle template library есть реализация вектора, которая
использует _mgrow (если он есть) для увеления размера хранилища. Если
кому интересно могу прислать.

--
С уважением,
Alex Besogonov (alexy@izh.com)

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

Д>>если хорошенько подумать, то подавляющее большинство объектов имеет небольшое время жизни — в одной функции выделили, в другой поюзали и удалили

GN>Если эту идею развить, может оказаться, что заметную часть этого большинства можно выделять и удалять в одной функции, для чего хорошо подходят автоматические объекты. Создание и удаление можно считать бесплатными.

Нифига. Ты платишь за стек — время копеечное, зато пространство дорогущее.
1) Сразу возникает ограничение на глубину рекурсии.
2) Освобождение памяти нетривиально, поэтому отделываются полным сбросом всех выделенных блоков при выходе из функции: _alloca есть, а _freea — нет
3) Выделение произвольного блока — по причинам 1) и 2) подрывает безопасность программы. Достаточно сделать _alloca в цикле.
Поэтому _alloca (или её аналогов) в стандартных библиотеках большинства языков нет.
Разве что в Форте, для которого динамическое выделение-освобождение — настолько редкая работа, что базовая куча, фактически, представляет собой ещё один стек.

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

GN>>Если эту идею развить, может оказаться, что заметную часть этого большинства можно выделять и удалять в одной функции, для чего хорошо подходят автоматические объекты. Создание и удаление можно считать бесплатными.

К>Нифига. Ты платишь за стек — время копеечное, зато пространство дорогущее.
К>1) Сразу возникает ограничение на глубину рекурсии.

Верно. Но (глубокая) рекурсия достаточно редка, что бы это было критическим моментом.
Кстати, если говорить о windows, то размер стека там равен по умолчанию размеру кучи.

К>2) Освобождение памяти нетривиально, поэтому отделываются полным сбросом всех выделенных блоков при выходе из функции: _alloca есть, а _freea — нет
К>3) Выделение произвольного блока — по причинам 1) и 2) подрывает безопасность программы. Достаточно сделать _alloca в цикле.

У многих объектов размер известен на стадии компиляции, другие объекты располагать на стеке — нужно 7 раз подумать.

К>Поэтому _alloca (или её аналогов) в стандартных библиотеках большинства языков нет.

А в С99 добавили в язык variable length array type. Пускай они даже реально на куче распологаться будут — синтаксис проще, и гарантирована "сборка мусора" при выходе из блока. Именно последнее я и считаю плюсами подхода. Даже если всё будет распологаться не в стеке, а в куче — не будет фрагментации, и создание + удаление останутся так же почти бесплатны, поскольку порядок этих операций гарантирован.

К>Разве что в Форте, для которого динамическое выделение-освобождение — настолько редкая работа, что базовая куча, фактически, представляет собой ещё один стек.

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

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

GN>ИМХО такие вещи не являются рутиной — делаются на автомате, как расстановка скобочек.

Нельзя заниматься бездумно такой задачей, как управлением памятью — можно оказаться в очень крупном пролете.
Такие вещи надо делать или тщательно обдумав, или отдавать на откуп автоматической системе.
И вообще, лучше не будем развивать эту тему. А то опять понабегут фанатики и начнут бить себя пяткой в грудь.

Здравствуйте, Дарней,

GN>>ИМХО такие вещи не являются рутиной — делаются на автомате, как расстановка скобочек.

Д>Нельзя заниматься бездумно такой задачей, как управлением памятью — можно оказаться в очень крупном пролете.

Я имел ввиду не управление памятью в целом, а использование объектов, тем или иным образом уже инкапсулирующих управление памяти в себе — будь то GC, RAII или ещё что-то. То есть, где подумать надо один раз, а не для каждого экземпляра.

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

GN>RAII или ещё что-то. То есть, где подумать надо один раз, а не для каждого экземпляра.

честно говоря, не понимаю, что ты имеешь в виду
если использовать RAII, то думать надо как раз для каждого экземпляра — как минимум, думать, подойдет ли для данной переменной RAII вообще
даже если ты не собираешься возвращать эту переменную из функции, всегда найдется подходящее место для пары граблей

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

C>Нужна другая функция, которая должна пытаться увеличить размер блока, но
C>в случае неудачи возвращать NULL, а не делать автоматическое выделение и
C>перемещение. В MSVC для этого есть нестандартная функция _mgrow.

И вполне стандартное

HeapReAlloc

HEAP_REALLOC_IN_PLACE_ONLY Specifies that there can be no movement when reallocating a memory block to a larger size.
If this flag is not specified and the reallocation request is for a larger size, the function might move the block to a new location.

If this flag is specified and the block cannot be enlarged without moving, the function fails, leaving the original memory block unchanged.

Pavel Dvorkin wrote:

> C>Нужна другая функция, которая должна пытаться увеличить размер
> блока, но
> C>в случае неудачи возвращать NULL, а не делать автоматическое
> выделение и
> C>перемещение. В MSVC для этого есть нестандартная функция _mgrow.
> И вполне стандартное
> HeapReAlloc

А Win32 у нас уже стандартный? Я говорил про ANSI/POSIX стандарты.

--
С уважением,
Alex Besogonov (alexy@izh.com)

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

C>А Win32 у нас уже стандартный? Я говорил про ANSI/POSIX стандарты.

А, тогда да.

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

Поздравляю — это хорошая, проверенная временем идея. Эта схема называется Slab Allocation, и она действительно очень эффективна. Такой аллокатор применяется, например, в оперсистеме Solaris, и в продуктах компании CQG, где я недавно работал.

Только при ее реализации придется решить ряд интересных инженерных проблем, для того, чтобы действительно получилось O(1). Дьявол в деталях — вы должны экономно подходить к расходованию адресного пространства у вас будет много хипов — надо разработать эффективную схему управления ими. Например — интересна проблема быстрого (за O(1)) определения адреса хипа по указателю на выделенный блок . Проблема решаемая. Аллокатор CQG тратит по нескольку машинных инструкций на выделение и деаллокацию. Разумеется, алгоритмы покрыты NDA.

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

Д>честно говоря, не понимаю, что ты имеешь в виду

Например, Re: delete && Qt

Автор: Dair
Дата: 11.12.05

. Пример, можно сказать, неудачный в моём контексте, но он показывает, что можно подумать один раз при дизайне классса, а можно — каждый раз при создании экземпляра.

Больше я не имел ввиду ничего

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

[]

И решение от CQG — платформонезависимое, или портабельное ?

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

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

S>[]

S>И решение от CQG — платформонезависимое, или портабельное ?

Только Win32, причем только 32 битные платформы (!) с адресным пространством 2Гб на процесс. И только для своих продуктов — оно не продается. Сделано в рамках работ по улучшению работы legacy клиента и сервера. Результат предельно практический — время старта системы сокращено в несколько раз .

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

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

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

S>>[]

S>>И решение от CQG — платформонезависимое, или портабельное ?

G>Только Win32, причем только 32 битные платформы (!) с адресным пространством 2Гб на процесс. И только для своих продуктов — оно не продается. Сделано в рамках работ по улучшению работы legacy клиента и сервера. Результат предельно практический — время старта системы сокращено в несколько раз .

Нюансы адресации памяти для выделения места в адресе блока под признак кучи