Функция из сторонней библиотеки (написанной на С) возвращает указатель Р на массив типизированных записей (Type, Type, Type и т.д.) и N - количество этих записей. Собственно вопрос: как освободить занимаемую этими записями память? Функции типа dispose (Р) и FreeMem(Р) дают ошибку «Неверный указатель»

Это сообщение отредактировал(а) Matrex - 5.3.2009, 14:45

Добавлено через 1 минуту и 25 секунд
не претендует на истину

Если бы… Не все так просто… Все равно наблюдается рост памяти. Я думаю, что связано это с представлением данных, которые эта функция возвращает: т.е. функция возвращает не массив указателей, а просто последовательность данных определенной структуры, поэтому указывая dispose (Р) или FreeMem(Р) или P:=nil я в лучшем случае обнулю только первую запись… Вот пример кода:



Это сообщение отредактировал(а) Matrex - 5.3.2009, 15:13

Matrex, это ошибка проектирования, если необходимая функция не экспортируется то освободить память нельзя. 
Р := nil; освобождает интерфейс или автоматический объект делфи. 

В описании функции должно быть указано, как следует освобождать после неё память. Для этого часто из библиотеки экспортируется спец. функция очистки. Иногда в качестве таковой выступает системная, например, LocalFree.
Пытаться освободить память дельфическим менеджером памяти - принципиально неверно.

Ясно. Спасибо за ответы.

Это сообщение отредактировал(а) Matrex - 5.3.2009, 15:40

скорее всего освобождением памяти занимается сама библиотека...
кстати, приведен жуткий код) который можно местами упростить

Как то не могу понять эту фразу, а можно выбрать какой я хочу использовать менеджер памяти? ведь менеджер память работает без ведома пользователя, надо тебе менджер памяти выделил память, надо удалил. Может быть я неправ

  Менеджеры памяти разные бывают, почему они должны быть совместимы?

Чем выделял - тем и надо освобождать.
Т.е. в данном случае тем, чем "выделяла" ф-ия.

Ну в Делфи стоит же единственный менеджер памяти,можно ли взять какой то чужой менеджер  вместо стандартного делфийского?

И FreeMem, и Dispose и об-nil-ние интерфейсов и массивов, и очистка строк - все они вызывают одну и ту же стандартную системную функцию _FreeMem. Которая, по-умолчанию, вызывает функцию освобождения памяти стандартного менеджера Delphi MemoryManager.FreeMem.


Можно. Для этого достаточно вызвать SetMemoryManager, предварительно вписав в структуру TMemoryManager указатели на управляющие функции. 
Вопрос в другом: а где ты его возьмёшь, этот чужой менеджер памяти? Библиотека писана на C. Там используется какой-то внутренний менеджер памяти, доступа к которому у тебя нет никакого. Точно так же, как библиотека, писанная на Delphi, не выставляет наружу никаких функций (а особенно управление менеджером памяти), пока ты явно это не укажешь в exports. Ну и как ты до достучишся до чужого менеджера памяти? Никак. Поэтому библиотека и должна предоставлять функцию освобождения памяти.

Но даже, если бы вдруг у тебя на руках чудесным образом оказались бы указатели на чей-то чужой менеджер памяти, заменять им свой - крайне плохая идея. И вот почему. До того момента, как вы получили в свои руки чужой менеджер памяти и установили его, у вас уже выделена целая куча памяти. Любой блок может быть освобождён сразу после того, как вы установите новый менеджер. Но запрос-то на освобождение придёт не вашему менеджеру, а чужому! Который про этот блок памяти ничего не знает! Например:



И наоборот. Поработали, выгружаем библиотеку. А при выгрузке менеджер памяти библиотеки финализируется и освобождает всю выделенную им память:



Именно поэтому нужно чётко разграничивать: какие блоки памяти ты выделил сам, а какие - выделил тебе чужой дядька. И свою память ты освобождаешь сам, а чужую - отдаёшь обратно дядьке на освобождение.

Добавлено @ 11:29
Да, если бы:
1). Библиотека была бы статически связана с твоим exe, а не грузилась бы динамически.
и
2). Менеджер памяти или в exe или в библиотеке заменялся бы на чужой автоматически загрузчиком ОС.

То использование чужого ММ было бы вполне безопасно.

Но это подразумевает, что:
1). Библиотеки нельзя будет загружать динамически!
2). Существует какой-то стандарт на MM ВСЕХ библиотек, писанных в ЛЮБЫХ языках (чего нет) (*).
3). Загрузчик ОС как-то определяет, кому отдать предпочтение: то-ли подпихнуть в exe менеджер памяти в библиотеке, то-ли подпихнуть в библиотеку менеджер памяти в exe. А если к тому же эти MM отличаются по эффективности в разы, то при неудачном выборе не миновать табуретки в мониторе.

Разделяемый менеджер памяти (типа ShareMem, SimpleShareMem или в виде пакета) решает эту задачу таким образом, что менеджер памяти устанавливается ПЕРВЫМ же действием в программе. При этом используется само-придуманный стандарт. Который могут использовать только те, кто про него в курсе. А это как правило, только Delphi или C++ Builder приложения.

Примечание:
(*) Не уверен, как с этим обстоит дело в .NET.

Это сообщение отредактировал(а) CodeMonkey - 6.3.2009, 12:06

спасибо немного разобрался,CodeMonkey, +1