Or предыдущего случая этот пример отличается только тем, что в нем нет вызовов
UniqueString
, и строки указывают на литералы в сегменте кода, которые никогда не удаляются. На экране получаем вполне ожидаемое Привет!. Обнулять указатель здесь уже нет смысла, потому что освобождать литерал менеджер памяти все равно не будет. Так ошибка оказалась скрытой.
Продолжим наши эксперименты. Запустим пример RecordCopy и понажимаем попеременно кнопки
Button1
и
Button2
. Мы видим, что результат не зависит от порядка, в котором мы нажимаем кнопки.
Модифицируем код в локальной процедуре обработчика
Button1Click
: уберем из строки "Hello!!!" восклицательные знаки, сократив ее до "Hello". Теперь можно наблюдать интересный эффект: если после запуска
нажать сначала
Button1
, то никаких изменений мы не заметим. А вот если кнопка
Button2
будет нажата раньше, чем
Button1
, то при последующих нажатиях
Button1
никаких видимых эффектов не будет. Это связано с тем, что теперь строка "Hello" не равна по длине строке "Good bye", поэтому разместится ли "Good bye" в том же месте памяти, где раньше была "Hello", или в каком-то другом, зависит от истории выделения и освобождения памяти. Если мы начинаем "с чистого листа", память после строки "Hello" останется свободной, поэтому туда можно поставить более длинную строку. А вот если раньше память уже выделялась и освобождалась (внутри методов
TLabel
), то тот кусочек свободной памяти, который достаточен для "Hello", слишком мал для "Good bye", и эта строка размещается в другом месте. А там, куда указывает
Rec.Str
, остается мусор, работать с которым нормально невозможно, поэтому при попытке присвоить его свойству
Label1.Caption
последнее не меняется (эффект наблюдается только до Delphi 7 включительно; в более новых версиях Delphi используется новый менеджер памяти FastMem, который немного по-другому размещает строки в памяти, поэтому с ним зависимости от порядка нажатия кнопок не будет).
Примечание
Если увеличить длину строки "Привет!" хотя бы на один символ, чтобы она была не короче, чем "Good bye" (или наоборот, сократить его так. чтобы оно стало короче "Hello"), мы снова увидим, что порядок нажатия кнопок не влияет на результат. Это происходит потому, что строка "Hello" размещается там, где раньше была строка "Привет!", а вот "Good bye" там уже не помещается. Если же обе строки там помещаются (или обе не помещаются), они снова оказываются в одной области памяти. Внимательный читатель может спросить: а при чем здесь длина строки "Привет!", если эта строка хранится в сегменте кода и никогда не освобождается? Дело в том, что когда мы присваиваем эту строку свойству
Label1.Caption
, внутри методов
TLabel
происходит ее перенос в динамическую память для внутренних нужд этого класса.
Даже на таком простом примере видно, насколько коварна эта ошибка и как незначительные изменения в коде могут кардинально изменить ее проявления. Между тем приведенный здесь код — плод долгого "приручения" этой ошибки, чтобы она всегда проявлялась предсказуемым образом. Но даже сейчас мы не можем дать полной гарантии, что у кого-то из читателей из-за какой-то неучтенной мелочи не возникнет ситуация, когда эта ошибка проявляется как-то по-другому (как мы уже видели, даже в разных версиях Delphi эта ошибка проявляет себя немного по-разному). В реальных проектах все гораздо сложнее, и поведение программы из-за этой ошибки может стать таким неожиданным, а проявление этой ошибки — настолько далеким от того места, где она сделана, что впору будет "прыгать вокруг компьютера с бубном", изгоняя бесов. Чтобы не оказаться в таком положении, нужно очень аккуратно работать со строками (а также с другими автоматически финализируемыми типами: динамическими массивами, интерфейсами, вариантами), чтобы тот код, который неявно генерирует компилятор, не оказался в тупике. Чаще всего проблемы возникают при побайтном копировании переменной типа
AnsiString
(не обязательно в составе записи) или при работе с ней как с указателем другого типа. Это не значит, что приводить
AnsiString
к другим указателям категорически нельзя — ранее мы уже делали это, и вполне успешно. Но, применяя любой низкоуровневый инструмент к таким строкам, разработчик должен четко представлять, как это отразится на внутренних механизмах работы с ними. Иначе — вот такая непонятная ошибка.
Еще одна ситуация, когда записи со строками могут преподнести сюрприз — выделение динамический памяти для них. Динамическую память можно выделить двумя способами: с помощью процедуры
New
или
GetMem
(освобождать ее надо, соответственно, с помощью
Dispose
или
FreeMem
). Для записей, не содержащих строки, эти способы практически эквивалентны, за исключением того, что при использовании
New
объем выделяемой памяти определяет компилятор, поэтому
New
считается более безопасным вариантом. Если же запись содержит строку, то эта строка должна быть инициализирована, иначе попытка работы с ней приведет к ошибке. Процедура
GetMem
ничего не делает с содержимым выделяемой ею памяти, и строка остается неинициализированной, в то время как
New
выполняет инициализацию. Это не значит, что
GetMem
непригодна для выделения памяти для такой записи, просто после вызова
GetMem
нужно не забыть вызвать специальную процедуру
Initialize
, которая правильно инициализирует строки в записи. Соответственно, прежде чем удалить такую запись с помощью
FreeMem
, необходимо вызвать процедуру
Finalize
для финализации строк. Это создает дополнительные проблемы, не давая никаких преимуществ, поэтому целесообразнее все-таки использовать
New
и
Dispose
.
Преимущество
GetMem
перед
New
заключается в том, что за один вызов
GetMem
можно выделить память сразу для нескольких записей (с последующей их ручной инициализацией, конечно же), в то время как
New
выделяет память только для одного экземпляра записи. Но с появлением в языке динамических массивов это преимущество тоже перестало быть особо полезным. Проще объявить динамический массив из записей и создать требуемое число элементов в нем — компилятор сам позаботится об инициализации таких переменных. Поэтому мы рекомендуем отказаться от
GetMem
при выделении памяти под записи со строками, а если уж вы столкнулись с ситуацией, когда без этого совсем никак, не забывайте вызывать
Initialize
и
Finalize
.
Примечание
Память для записей можно выделять и в обход менеджера памяти Delphi напрямую вызывая системные функции типа
HeapAlloc
,
VirtualAlloc
или
CoTaskMemAlloc
. Разумеется, компилятор в этом случае не сможет инициализировать и финализировать выделяемую память, поэтому, как и в случае с
GetMem
, для строк с записями необходимо пользоваться процедурами
Initialize
и
Finalize
.
3.3.9. Использование ShareMem
Пример, который мы сейчас рассмотрим, — это даже не "подводный камень", это то, что в форумах обычно называется "грабли". Все новые и новые программисты с завидным упорством наступают на эти грабли и получают по лбу, хотя, казалось бы, вокруг стоят таблички, предупреждающие об опасности, только не ленись читать.
Итак, создаем новую динамически компонуемую библиотеку (DLL). Delphi предлагает нам следующую заготовку (листинг 3.43).
Листинг 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, мы получим ошибку.