N>>по идее ведь второй цикл должен освободить все что занял первый, в чем дело?
G>а почему ты решил что он не освобождает
Да потому что прогоняю первый цикл, процесс съел до 8мб, а второй ничего не освободил.
Но что странно, если процедуру повторить, то все равно 8мб будет.
N>Да потому что прогоняю первый цикл, процесс съел до 8мб, а второй ничего не освободил. N>Но что странно, если процедуру повторить, то все равно 8мб будет.
Сишный runtime не возвращает операционной системе освободившуюся память.
Вот и все странности.
Здравствуйте, ilejn, Вы писали:
I>Здравствуйте, needle, Вы писали:
N>>Да потому что прогоняю первый цикл, процесс съел до 8мб, а второй ничего не освободил. N>>Но что странно, если процедуру повторить, то все равно 8мб будет.
I>Сишный runtime не возвращает операционной системе освободившуюся память. I>Вот и все странности.
а тогда как поэлементно очистить память от того что создается в первом цикле?
Здравствуйте, needle, Вы писали:
I>>Сишный runtime не возвращает операционной системе освободившуюся память. I>>Вот и все странности.
N>а тогда как поэлементно очистить память от того что создается в первом цикле?
Тебе сказали — память очищена. То, что runtime-библиотека не освободила память — ее дело. Можешь написать свой менеджер памяти, в нем пользуй напрямую методы выделения памяти операционной системы.
А теперь — главный вопрос: зачем тебе это надо? Тебя сильно напрягают 8MB? Я думаю, операционка сама разрулит эту ситуацию, например, неиспользиемые страницы может засвопить.
Результат, может, и тот же, но по стандарту память, выделенную с помощью new [], освобождать нужно с помощью delete [] и никак иначе.
По поводу же результата тебе уже объяснили ниже.
N>а тогда как поэлементно очистить память от того что создается в первом цикле?
Небольшое дополнение к сказанному.
Проблема (точнее говоря, некий эффект) никак не связана со спецификой приведенного примера.
Можно сделать один malloc, потом free, и убедиться, что память (скорее всего) операционной системе не вернули.
Если желание поуправлять размером адресного пространства процесса преодолеть не удается,
то ответ лежит в районе mallopt или чего-нибудь специфичного для используемого менеджера памяти.
Если еще глубже, то brk и sbrk, но это уже не Posix и
эти функции не предназначены для использования широкими народными массами.
Здравствуйте, ilejn, Вы писали:
I>Здравствуйте, needle, Вы писали:
N>>а тогда как поэлементно очистить память от того что создается в первом цикле?
I>Небольшое дополнение к сказанному.
I>Проблема (точнее говоря, некий эффект) никак не связана со спецификой приведенного примера. I>Можно сделать один malloc, потом free, и убедиться, что память (скорее всего) операционной системе не вернули.
I>Если желание поуправлять размером адресного пространства процесса преодолеть не удается, I>то ответ лежит в районе mallopt или чего-нибудь специфичного для используемого менеджера памяти.
I>Если еще глубже, то brk и sbrk, но это уже не Posix и I>эти функции не предназначены для использования широкими народными массами.
Ну чтож, спасибо всем, желание поуправлять преодолел, не хочу настолько углубляться )