Чтение онлайн

на главную

Жанры

О чём не пишут в книгах по Delphi

Григорьев Антон Борисович

Шрифт:
Листинг 3.43. Базовый

library Project1;

{ Important note about DLL memory management: ShareMem must be the first unit in your library's USES clause AND your project's (select Project-View Source) USES clause if your DLL exports any procedures or functions that pass strings as parameters or function results. This applies to all strings passed to and from your DLL--even those that are nested in records and classes. ShareMem is the interface unit to the BORLNDMM.DLL shared memory manager, which must be deployed along with your DLL. To avoid using BORLNDMM.DLL, pass string information using PChar or ShortString parameters. }

uses

 SysUtils, Classes;

{$R *.RES}

begin

end.

Самое

важное здесь — комментарий. Его следует внимательно прочитать и осознать, а главное — выполнить эти советы, иначе при передаче строк
AnsiString
между DLL и программой вы будете получать ошибку Access violation в самых неожиданных местах. Почему-то многие им пренебрегают, а потом бегут с вопросами в разные форумы, хотя минимум внимательности и отсутствия снобизма по отношению "к этим, из Borland'а, которые навставляли тут никому не нужных комментариев" могли бы уберечь от ошибки.

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

Менеджер памяти реализуется модулем

System
. Так как DLL компонуется отдельно от использующего ее exe-файла, у нее будет своя копия кода
System
, и, следовательно, свой менеджер памяти. И если объект, память для которого была выделена в коде основного модуля программы, попытаться освободить в коде DLL, то получится, что освобождать память будет совсем не тот менеджер, который ее выделил. А сделать он этого не сможет, т.к. не обладает информацией о выделенном блоке. Результат — ошибка (скорее всего, Access violation при выходе из процедуры). А при работе со строками
AnsiString
память постоянно выделяется и освобождается, поэтому, попытавшись работать с одной и той же строкой и в главном модуле, и в DLL, мы получим ошибку.

Теперь, когда мы поняли, почему возникает проблема, разберемся, как

ShareMem
ее решает. Delphi предоставляет возможность заменить стандартный менеджер памяти своим: для этого нужно написать низкоуровневые функции выделения, освобождения и перераспределения памяти и сообщить их адреса через процедуру
SetMemoryManager
. После этого через них будут работать все высокоуровневые функции для манипуляций с памятью (
New
,
GetMem
и т.п.). Именно это и делает
ShareMem
в секции инициализации этого модуля содержится код, заменяющий функции работы с памятью своими, которые находятся во внешней библиотеке BORLNDMM.DLL. Получается, что и библиотека, и главный модуль работают с одним менеджером памяти, что решает описанные проблемы.

Если менеджер памяти попытаться поменять не в самом начале программы, то ему придется освобождать память, которую успел выделить предыдущий менеджер памяти, что приведет к той же самой проблеме. Поэтому заменить менеджер памяти нужно до того, как будет выполнена первая операция по её выделению. Отсюда возникает требование вставлять

ShareMem
первым модулем в dpr-файлах главного модуля и DLL — чтобы его секция инициализации была первым выполняемым программой кодом.

В Интернете часто можно встретить утверждения, что в новых версиях Delphi (BDS2006 и выше)

ShareMem
не нужен, потому что стандартный менеджер памяти там заменен на
FastMM
, который прекрасно обходится без
ShareMem
. Это неверно. Оригинальный
FastMM
действительно может функционировать без
ShareMem
при выполнении определённых условий. Модуль, использующий
FastMM
("модуль" здесь значит модуль в понимании системы, т.е. module, а не unit), может предоставить свой менеджер памяти в общее пользование, а все остальные модули, подключившие
FastMM
будут пользоваться этим менеджером вместо своего. Получится, что все модули в процессе будут работать с одним менеджером памяти, и проблем не будет. В общее пользование
свой менеджер памяти предоставляет тот модуль, который инициализируется самым первым (т.к. основной модуль программы инициализируется только после того, как будут проинициализированы все статически связанные с ним DLL, в общее пользование свой менеджер памяти предоставляет одна из DLL).

Тот вариант

FastMM
, который входит в состав новых версий Delphi, тоже может быть предоставлен в общее пользование, но по умолчанию этого не происходит, так что с передачей строк в DLL возникнут те же проблемы, что и в старых версиях Delphi. Но решить эти проблемы теперь можно двумя способами. Первый — это использовать
ShareMem
и распространять с программой библиотеку BORLNDMM.dll, точно так же, как и в более ранних версиях Delphi. Второй способ — подключить к dpr-файлам библиотек и главного модуля модуль
SimpleShareMem
. Этот модуль в своей секции инициализации проверяет, есть ли уже переданный в общее пользование менеджер памяти, и если есть, переключает свою программу или DLL на него, а если ещё нет, делает текущий менеджер памяти общим. Использование модулей
SimpleShareMem
и
ShareMem
идентично: его так же нужно указывать первым в списке uses главного файла проекта. Но никаких дополнительных библиотек распространять с программой не придется. Таким образом, новые версии Delphi действительно позволяют обойтись без библиотеки BORLNDMM.DLL, но это все-таки получается не автоматически, а после некоторых усилий.

Кстати, к данному в комментарии совету заменить

AnsiString
на
PChar
, чтобы избавиться от необходимости использования
ShareMem
, следует относиться осторожно: если мы попытаемся, например, вызвать
StrNew
в основной программе, а
StrDispose
— в DLL, то получим ту же проблему. Вопрос не в типах данных, а в том, как манипулировать памятью. Поэтому обычный способ работы с
PChar
следующий: программа выделяет буфер своим менеджером памяти и передает указатель на этот буфер, а также его длину в качестве параметров функции из DLL. Эта функция заносит в буфер требуемую строку, не перераспределяя память. Затем программа освобождает эту строку своим же менеджером памяти. В листинге 3.44 приведен пример кода такой функции в DLL.

Листинг 3.44. Код функции в DLL

function GetString(Buf: PChar; BufLen: Integer): Integer;

var

 S: string;

begin

 // Формируем строку для возврата программе

 ...

 // Копируем строку в буфер

 if BufLen > 0 then StrLCopy(Buf, PChar(S), BufLen - 1);

 // возвращаем требуемый размер буфера

 Result := Length(S) + 1;

end;

Здесь параметр

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

Если не существует ограничения на длину возвращаемой строки, программа "не знает", буфер какого размера потребуется. Наиболее простое решение этой проблемы следующее: программа сначала вызывает функцию

GetString
, передавая
nil
в качестве указателя на буфер и 0 в качестве размера буфера. Затем по результату функции определяется требуемый размер буфера, выделяется память и функция вызывается еще раз, уже с буфером нужного размера. Такой способ обеспечивает правильную передачу строки любой длины, но требует двукратного вызова функции, что снижает производительность, особенно в том случае, если на формирование строки тратится много времени.

Поделиться:
Популярные книги

В зоне особого внимания

Иванов Дмитрий
12. Девяностые
Фантастика:
попаданцы
альтернативная история
5.00
рейтинг книги
В зоне особого внимания

Вечный Данж. Трилогия

Матисов Павел
Фантастика:
фэнтези
юмористическая фантастика
6.77
рейтинг книги
Вечный Данж. Трилогия

Холодный ветер перемен

Иванов Дмитрий
7. Девяностые
Фантастика:
попаданцы
альтернативная история
6.80
рейтинг книги
Холодный ветер перемен

Повелитель механического легиона. Том I

Лисицин Евгений
1. Повелитель механического легиона
Фантастика:
фэнтези
попаданцы
аниме
5.00
рейтинг книги
Повелитель механического легиона. Том I

Целитель

Первухин Андрей Евгеньевич
1. Целитель
Фантастика:
фэнтези
попаданцы
5.00
рейтинг книги
Целитель

Золушка вне правил

Шах Ольга
Любовные романы:
любовно-фантастические романы
6.83
рейтинг книги
Золушка вне правил

Свадьба по приказу, или Моя непокорная княжна

Чернованова Валерия Михайловна
Любовные романы:
любовно-фантастические романы
5.57
рейтинг книги
Свадьба по приказу, или Моя непокорная княжна

Мифы и Легенды. Тетралогия

Карелин Сергей Витальевич
Мифы и Легенды
Фантастика:
фэнтези
рпг
альтернативная история
5.00
рейтинг книги
Мифы и Легенды. Тетралогия

Газлайтер. Том 4

Володин Григорий
4. История Телепата
Фантастика:
попаданцы
альтернативная история
аниме
5.00
рейтинг книги
Газлайтер. Том 4

Мастер Разума

Кронос Александр
1. Мастер Разума
Фантастика:
героическая фантастика
попаданцы
аниме
6.20
рейтинг книги
Мастер Разума

Теневой Перевал

Осадчук Алексей Витальевич
8. Последняя жизнь
Фантастика:
попаданцы
аниме
фэнтези
5.00
рейтинг книги
Теневой Перевал

С Д. Том 16

Клеванский Кирилл Сергеевич
16. Сердце дракона
Фантастика:
боевая фантастика
6.94
рейтинг книги
С Д. Том 16

Купеческая дочь замуж не желает

Шах Ольга
Фантастика:
фэнтези
6.89
рейтинг книги
Купеческая дочь замуж не желает

Охота на попаданку. Бракованная жена

Герр Ольга
Любовные романы:
любовно-фантастические романы
5.60
рейтинг книги
Охота на попаданку. Бракованная жена