[salvian 0]

Перерыл почти всё, нигде не могу найти библиотечную функцию (видимо её вообще нет) или хотя бы самописную реализацию функции возвращающей количество байт свободного места в куче для DLib'овского менеджера памяти. Может кто занимался этим вопросом и подскажет варианты решения?

[zltigo 2]

Перерыл почти всё, нигде не могу найти библиотечную функцию (видимо её вообще нет)

Здравая мысль :)

или хотя бы самописную реализацию функции возвращающей количество байт свободного места в куче для DLib'овского менеджера памяти.

Без знания организации менеджера и доступа к его структурам это невозможно. Но исходники в pro версиях есть.

Может кто занимался этим вопросом и подскажет варианты решения?

Поскольку простейший менеджер яйца выеденного не стоит, то напишите/возьмите самописный. Один из вариантов (с комментариями почему именно так сделано) под свои нужды я даже на этом форуме выкладывал.

[jack_avenger 5]

salvian

Как успехи? Удалось получить объем свободной кучи? У меня аналогичная проблема.

 

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

[sergeeff 1]

salvian

Как успехи? Удалось получить объем свободной кучи? У меня аналогичная проблема.

 

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

 

Не мучайтесь. Возьмите аллокатор BGET (http://www.fourmilab.ch/bget/). Он уже лет 40 как в работе. Там есть все, что нужо, в том числе и статистика использования кучи.

[Xenia 45]

А мне всегда казалось, что размер кучи не определяют, а задают в проекте (там же, где задаются размеры стека/ов). Так зачем же определять, да еще и с помощью библиотечной функции, то, что заранее жестко задано?

[sergeeff 1]

А мне всегда казалось, что размер кучи не определяют, а задают в проекте (там же, где задаются размеры стека/ов). Так зачем же определять, да еще и с помощью библиотечной функции, то, что заранее жестко задано?

 

Речь идет, насколько я понимаю, именно о статистике загрузки кучи, а не о ее объеме. А именно, сколько блоков выделено, сколько памяти осталось и прочее. Очень полезно это знать при отладке на предмет оценки утечек памяти, например.

 

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

[Xenia 45]

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

Ничего подобного - исходники библиотек лежат в \scr\lib\, где с ними можно ознакомиться. А при желании даже перекомпилировать библиотеку по своему вкусу. Если у вас нет исходников, то это означает только то, что вы пользуетесь EV или KS версией компилятора, а не FULL.

[zltigo 2]

а задают в проекте...

Крайне порочный вариант :( используемый в примитивных менеджерах. Heap должна отдаваться вся оставшаяся свободная память, иначе дурдом - память есть, но не используется.

 

Чтоб написать свой менеджер памяти у меня опыта нет.

Ну так я уже писал, что на этом форуме выкладывал http://electronix.ru/forum/index.php?showt...mp;#entry746045

[sergeeff 1]

Ничего подобного - исходники библиотек лежат в \scr\lib\, где с ними можно ознакомиться. А при желании даже перекомпилировать библиотеку по своему вкусу. Если у вас нет исходников, то это означает только то, что вы пользуетесь EV или KS версией компилятора, а не FULL.

 

1. Если есть исходники, надо их почитать, понять и не морочить остальным голову.

2. Исходники исходникам рознь.

3. У меня все, что нужно - есть. И ветку эту не я затеял.

[salvian 0]

лучше поздно, чем никогда:

 

__iar_dlmallinfo()

__iar_dlmalloc_stats()

 

подробнее: http://supp.iar.com/Support/?note=28545