AHTUNG!!! Утечка

[Old]

На Mac OSX (linuх posix) штатная утилита Activity Monitor четко показывает что clear() все отдает. А что там делает та или иная версия Linuх - ее личное дело, повлиять на это все равно нельзя (на уровне прикладной программы). В общем, как в том анекдоте "это просто трусы линяют"  

Это почему?
Есть brk/sbrk, которой вы сможете регулировать размер распределенной памяти (и под MAC OSX, скорее всего, в том числе).
Только пока вы используете стандартный менеджер кучи, вам это вряд-ли понадобиться, ибо этим занимается он.

[GreatSnake]

На Mac OSX (linuх posix) штатная утилита Activity Monitor четко показывает что clear() все отдает. А что там делает та или иная версия Linuх - ее личное дело, повлиять на это все равно нельзя (на уровне прикладной программы). В общем, как в том анекдоте "это просто трусы линяют" 

Версия Linux тут не причём, всё упирается в версию malloc. Везде они разные. Через LD_PRELOAD можно её легко подменить любому приложению (не статик, конечно).
Кстати, Mac OSX это надстройка над Darwin, которая к linuх не имеет никакого отношения, т.к. выросла из FreeBSD)

[Igors]

Есть brk/sbrk, которой вы сможете регулировать размер распределенной памяти

Насколько я помню, эти старомодные ф-ции меняют размер сегмента данных, а не кучи.

Версия Linux тут не причём, всё упирается в версию malloc. Везде они разные. Через LD_PRELOAD можно её легко подменить любому приложению (не статик, конечно).

Пусть так, и что прикладная прога может реально предпринять? Изменить механизм страниц - нет. Написать свой менеджер кучи - явно неуместный велосипед. Что еще?

Кстати, Mac OSX это надстройка над Darwin, которая к linuх не имеет никакого отношения, т.к. выросла из FreeBSD)

Linuх, FreeBSD, Darwin - во всяком случае одно "nix" семейство. Возвращаясь к теме - ответ тот же - оставить как есть и полагаться на ОС

[Old]

Насколько я помню, эти старомодные ф-ции меняют размер сегмента данных, а не кучи.

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

Написать свой менеджер кучи - явно неуместный велосипед. Что еще?

Это для вас он не уместный и я даже знаю почему, это не FindReplace для std::string написать.

[Igors]

Это для вас он не уместный и я даже знаю почему,

Ну так если для Вас уместный - реализуйте и выкладывайте здесь, обсудим 

[GreatSnake]

Пусть так, и что прикладная прога может реально предпринять? Изменить механизм страниц - нет. Написать свой менеджер кучи - явно неуместный велосипед. Что еще?

Воспользоваться сторонним МП (менеджер памяти), благо их хватает.

Возвращаясь к теме - ответ тот же - оставить как есть и полагаться на ОС

Опять-двадцать пять...
Причём здесь ОС, если МП по сути является частью приложения?

[merke]

Практически тоже самое наблюдал сейчас под Windows. При старте приложухи по диспетчеру задач она заняла 8 мб памяти. После работы и очистки памяти был всплеск до 27 мб, но сбросилось до 10 мб по окончанию, получается куда то делись 2 мб памяти, неужели винда ведет себя также как Linux. Чтобы выяснить это - решил сделать следующий эксперимент: запустил первый процесс при запуске также 8 мб, после работы 10 мб. Начал запускать еще копии таких же приложух, пока не забил всю свободную оперативную память и в тот момент когда уже начал лезть в своп, начал наблюдать завораживающую взгляд картину, первый процесс стал "худеть", сначала сбросил с 10 мб до 7 мб, а потом и вовсе до 2,5 мб. Вуаля, вывод: реально мое тестовое приложение занимает в оперативе 2,5 мб все остальное место он себе натырил как бобер за щеки - на будущее, а как системе стало не хватать оперативы, она начала забирать резервированную память у процессов. Вот такая вот интересная картина получается...

[Old]

Ну так если для Вас уместный - реализуйте и выкладывайте здесь, обсудим 

А что в этом вопросе с вами можно обсудить? Вы же понятия не имеете о чем идет речь:

Насколько я помню, эти старомодные ф-ции меняют размер сегмента данных, а не кучи.