Читать онлайн «О чём не пишут в книгах по Delphi». Страница 106

 Stream.Free;

 Label1.Caption :=

  TimeToStr(EncodeTime(Rec.Hour, Rec.Minute, Rec.Second, Rec.MSec));

 Label2.Caption := Rec.Msg; { * }

end;

Примечание

В проекте RecordRead объявлена такая же запись TMethod1Record, описание которой во втором случае для краткости опущено.

Запись в файл происходит нормально, но при чтении в строке, отмеченной звездочкой, скорее всего, возникает исключение Access violation (в некоторых случаях исключения может не быть, но вместо сообщения будет выведен мусор). Причину этого мы уже обсудили ранее — указатель Msg, действительный в контексте процесса RecordWrite, не имеет смысла в процессе RecordRead, а сама строка передана не была. Без ошибок этим методом можно передать только пустую строку, потому что ей соответствует указатель nil, имеющий одинаковый смысл во всех процессах. Однако метод передачи строк, умеющий передавать только пустые строки, имеет весьма сомнительную ценность с практической точки зрения.

Самый простой способ исправить ситуацию— изменить тип поля Msg на ShortString. Больше ничего в приведенном коде менять не придется. Однако использование ShortString имеет два недостатка. Во-первых, длина строки в этом случае ограничена 255 символами. Во-вторых, если длина строки меньше максимально возможной, часть памяти, выделенной для структуры, останется незаполненной. Если средняя длина строки существенно меньше максимальной, то таких неиспользуемых кусков в потоке будет много, т.е. файл окажется неоправданно раздутым. Это всегда плохо, а в некоторых случаях — вообще недопустимо, поэтому ShortString можно посоветовать только в тех случаях, когда строки имеют примерно одинаковую длину (напомним, что ShortString позволяет ограничить длину строки меньшим, чем 255, числом символов — в этом случае поле будет занимать меньше места).

С одним из этих недостатков можно бороться: если заменить в записи ShortString статическим массивом типа Char, то можно передавать строки большей, чем 255 символов, длины. Второй метод демонстрирует этот способ.

В проекте RecordWrite этому соответствует код (листинг 3.37).

Листинг 3.37. Запись в файл структуры с массивом символов

const

 MsgLen = 15;

type

 TMethod2Record = packed record

  Hour: Word;

  Minute: Word;

  Second: Word;

  MSec: Word;

  Msg: array[0..MsgLen - 1] of Char;

 end;

procedure TForm1.Button2Click(Sender: TObject);

var

 Rес: TMethod2Record;

 Stream: TFileStream;

begin

 DecodeTime(Now, Rec.Hour, Rec.Minute, Rес.Second, Rec.MSec);

 StrPLCopy(Rec.Msg, Edit1.Text, MsgLen - 1);

 Stream := TFileStream.Create('Method2.stm', fmCreate);

 Stream.WriteBuffer(Rec, SizeOf(Rec));

 Stream.Free;

end;

В проекте RecordRead это следующий код (листинг 3.38).

Листинг 3.38. Чтение из файла структуры с массивом символов

procedure TForm1.Button2Click(Sender: TObject);

var

 Rес: TMethod2Record;

 Stream: TFileStream;

begin

 Stream := TFileStream.Create('Method2.stm', fmOpenRead);

 Stream.ReadBuffer(Rec, SizeOf(Rec));

 Stream.Free;

 Label1.Caption :=

  TimeToStr(EncodeTime(Rec.Hour, Rec.Minute, Rec.Second, Rec.MSec));

 Label2.Caption := Rec.Msg;

end;

Константа MsgLen задаёт максимальную (вместе с завершающим нулём) длину строки. В приведенном примере она взята достаточно маленькой, чтобы наглядно продемонстрировать, что данный метод имеет ограничения на длину строки. Переделки по сравнению с кодом предыдущего метода минимальны: при записи для копирования значения Edit1.Text вместо присваивания нужно вызывать функцию StrPLCopy. В коде RecordRead изменений (за исключением описания самой структуры) вообще нет — это достигается за счёт того, что массив Char считается компилятором совместимым с PChar, а выражения типа PChar могут быть присвоены переменным типа AnsiString — конвертирование выполнится автоматически.

Однако проблему неэффективного использования файлового пространства мы таким образом не решили. Более того, мы до конца не решили и проблему максимальной длины: хотя ограничение на длину строки теперь может быть произвольным, всё равно оно должно быть известно на этапе компиляции. Чтобы полностью избавиться от этих проблем, необходимо вынести строку за пределы записи и сохранить её отдельно, вместе с длиной, чтобы при чтении сначала читалась длина строки, затем выделялась для неё память, и в эту память читалась строка. Именно так работает третий метод. В проекте Record Write это будет следующий код (листинг 3.39)

Листинг 3.39. Запись в файл строки отдельно от структуры

type

 TMethod3Record = packed record

  Hour: Word;

  Minute: Word;

  Second: Word;

  MSec: Word;

 end;

procedure TForm1.Butrton3Click(Sender: TObject);

var

 Rec: TMethod3Record;

 Stream: TFileStream;

 Msg: string;

 MsgLen: Integer;

begin

 DecodeTime(Now, Rec.Hour, Rec.Minute, Rec.Second, Rec.MSec);

 Msg := Edit1.Text;

 MsgLen := Length(Msg);

 Stream := TFileStream.Create('Method3.stm', fmCreate);

 Stream.WriteBuffer(Rec, SizeOf(Rec));

 Stream.WriteBuffer(MsgLen, SizeOf(MsgLen);

 if MsgLen > 0 then Stream.WriteBuffer(Pointer(Msg)^, MsgLen);

 Stream.Free;

end; 

В проекте RecordRead это следующий код (листинг 3.40).

Листинг 3.40. Чтение из файла строки отдельно от структуры

procedure TForm1.Button3Click(Sender: TObject);

var

 Rec: TMethod3Record;

 Stream: TFileStream;

 Msg: string; MsgLen:

 Integer;

begin

 Stream := TFileStream.Create('Method3.stm', fmOpenRead);

 Stream.ReadBuffer(Rec, SizeOf(Rec));

 Stream.ReadBuffer(MsgLen, SizeOf(Integer));

 SetLength(Msg, MsgLen);

 if MsgLen > 0 then Stream.ReadBuffer(Pointer(Msg)^, MsgLen);

 Stream.Free;

 Label1.Caption :=

  TimeToStr(EncodeTime(Rec.Hour, Rec.Minute, Rec.Second, Rec.MSec));

 Label2.Caption := Msg;

end;

Наконец-то мы получили код, который безошибочно передает строку, не имея при этом ограничений длины (кроме ограничения на длину AnsiString) и не расходуя понапрасну память. Правда, сам код получился сложнее. Во-первых, из записи исключено поле типа string, и теперь ее можно без проблем читать и писать в поток. Во-вторых, в поток после нее записывается длина строки. В-третьих, записывается сама строка.

Параметры вызова методов ReadBuffer и WriteBuffer для чтения/записи строки требуют дополнительного комментария. Метод WriteBuffer пишет в поток ту область памяти, которую занимает указанный в качестве первого параметра объект. Если бы мы указали саму переменную Msg, то записалась бы та часть памяти, которую занимает эта переменная, т.е. сам указатель. А нам не нужен указатель, нам необходима та область памяти, на которую он указывает, поэтому указатель следует разыменовать с помощью оператора ^. Но просто взять и применить этот оператор к переменной Msg нельзя — с точки зрения синтаксиса она не является указателем. Поэтому приходится сначала приводить ее к указателю (здесь подошел бы любой указатель, не обязательно нетипизированный). То же самое относится и к ReadBuffer: чтобы прочитанные данные укладывались не туда, где хранится указатель на строку, а туда, где хранится сама строка, приходится прибегнуть к такой же конструкции. И обратите внимание, что прежде чем читать строку, нужно зарезервировать для нее память с помощью SetLength.

Вместо приведения строки к указателю с последующим его разыменованием можно было бы использовать другие конструкции:

Stream.ReadBuffer(Msg[1], MsgLen);

и

Stream.WriteBuffer(Msg[1], MsgLen);

Это дает требуемый результат и даже более наглядно: действительно, при чтении и записи мы работаем с той областью памяти, которая начинается с первого символа строки, т.е. с той, где хранится сама строка. Но такой способ менее производителен из-за неявного вызова UniqueString. В нашем случае мы и так защищены от побочных изменений других строк (при записи строка не меняется, при чтении она и так уникальна — это обеспечивает SetLength), поэтому вполне можем обойтись без этой в данном случае излишней опеки со стороны компилятора.

Примечание

Если сделать MsgLen не независимой переменной, а полем записи, можно сэкономить на одном вызове ReadBuffer и WriteBuffer.

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