А. Григорьев - О чём не пишут в книгах по Delphi

3.3.6. Нулевой символ в середине строки

Хотя символ #0 и добавляется в конец каждой строки AnsiString, он уже не является признаком ее конца, т.к. длина строки хранится отдельно. Это позволяет размещать символы #0 и в середине строки. Но нужно учитывать, что полноценное преобразование такой строки в PChar невозможно — это иллюстрируется примером Zero на компакт-диске (листинг 3.32).

procedure TForm1.Button1Click(Sender: TObject);

var

 S1, S2, S3: string;

 P: PChar;

begin

 S1 := 'Test'#0'Test';

 S2 := S1;

 UniqueString(S2);

 P := PChar(S1);

 S3 := P;

 Label1.Caption := IntToStr(Length(S2));

 Label2.Caption := IntToStr(Length(S3));

end;

В первую метку будет выведено число 9 (длина исходной строки), во вторую — 4. Мы видим, что при копировании одной строки AnsiString в другую символ #0 в середине строки — не помеха (вызов UniqueString добавлен для того, чтобы обеспечить реальное копирование строки, а не только копирование указателя). А вот как только мы превращаем эту строку PChar, информация о ее истинной длине теряется, и при обратном преобразовании компилятор ориентируется на символ #0, в результате чего строка "обрубается".

Потеря куска строки после символа #0 происходит всегда, когда есть преобразование ShortString или AnsiString в PChar, даже неявное. Например, все API-функции работают с нуль-терминированными строками, а визуальные компоненты — просто обертки над этими функциями, поэтому вывести с их помощью на экран строку, содержащую #0, целиком невозможно. Но главный "подводный камень", связанный с символом #0 в середине строки, заключается в том, что целый ряд стандартных функций для работы со строками AnsiString на самом деле вызывают API-функции (или даже библиотечные функции Delphi, предназначенные для работы с PChar, что приводит к игнорированию "хвоста" после #0. Следующий код (листинг 3.33. пример ZeroFind на компакт-диске) иллюстрирует эту проблему.

procedure TForm1.Button1Click(Sender: TObject);

begin

 Label1.Caption := IntToStr(AnsiPos('Z', 'A'#0'Z'));

end;

Хотя символ "Z" присутствует в строке, в которой производится поиск, на экран будет выведен "0", что означает отсутствие искомой подстроки. Это связано с тем, что функция AnsiPos использует функции StrPos и CompareString, предназначенные для работы со строками PChar, поэтому поиск за символом #0, не производится. Если заменить в этом примере функцию AnsiPos на Pos, которая работает с типом AnsiString должным образом, на экран будет выведено правильное значение "3".

Описанные проблемы заставляют очень осторожно относиться к возможному появлению символа #0 в середине строк AnsiString — это может стать источником неожиданных проблем.

Очень интересный "подводный камень", связанный с типом AnsiString рассмотрен в статье [4]. Проиллюстрируем его следующим кодом (листинг 3.34, пример StringResult на компакт-диске).

function AddOne: string;

begin

 Result := Result + '1';

end;

procedure TForm1.Button1Click(Sender: TObject);

var

 S: string;

begin

 S := 'Test';

 S := AddOne;

 Label1.Caption := S;

end;

Если человека, не знакомого с этой особенностью компилятора, попросить предсказать, что появится на экране в результате выполнения этого кода, его рассуждения будут звучать, скорее всего, примерно так: "Так как Result в функции AddOne — это локальная переменная типа string, то, как и все такие переменные, она будет инициализирована пустым значением. Добавление символа '1' к пустой строке даст в результате строку '1', которая и будет выведена на экран. Кстати, на строке S := 'Test' компилятор должен выдать предупреждение, что значение, присвоенное переменной S, нигде не используется".

Однако эти рассуждения неверны. На экране появится надпись Test1, т.е. первоначальное значение переменной S будет учтено в функции AddOne. Это происходит потому, что с точки зрения двоичного кода переменная Result это не локальная переменная, а параметр-переменная, как если бы функции AddOne была объявлена так:

procedure AddOne(var Result: string); 

Именно так компилятор обрабатывает функции, тип результата которых AnsiString (и ShortString, кстати, тоже). Какая переменная будет передана в качестве параметра, — это зависит от того, как вызвана функция, точнее, куда идет ее результат. Иногда компилятору приходится неявно имитировать какую-то переменную, а иногда он может воспользоваться реально существующей переменной. В нашем случае он воспользовался переменной S, передав её в качестве параметра. Строковые параметры-переменные, в отличие от локальных переменных, по понятным причинам не инициализируются пустой строкой, поэтому переменная Result сохраняет значение переменной S, что и приводит к наблюдаемому результату.

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

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

Поля в записях могут иметь любой строковый тип без дополнительных ограничений. Однако следует учитывать, что, в отличие от полей простых типов, значения полей типа PChar и AnsiString лежат вне пределов структуры, причем в случае AnsiString это не так бросается в глаза, т.к вручную выделять и освобождать память не приходится. Это может привести к неприятному сюрпризу, если работать со структурой как с цельным блоком данных. Чаще всего проблема появляется при записи структуры в поток, файл и т.п. В этом случае записывается только значение указателя, которое не имеет никакого смысла для того, кто потом эти данные читает, такой указатель указывает либо в никуда, либо на данные, никакого отношения к строке не имеющие.

Для иллюстрации этой проблемы, а также методов её решения нам понадобятся два проекта: RecordRead и RecordWrite (на компакт-диске они оба находятся в папке RecordReadWrite). Обойтись одним проектом здесь нельзя — указатель, переданный в пределах проекта, остается корректным, поэтому проблема маскируется. В проекте RecordWrite три кнопки, соответствующие трем методам сохранения записи в поток TFileStream (в файлы Method1.stm, Method2.stm и Method3.stm соответственно). В три целочисленных поля заносятся текущие час, минута, секунда и сотая доля секунды, строка — произвольная, введенная пользователем в поле ввода Edit1. Файлы пишутся в текущую папку, из-за этого программы нельзя запускать непосредственно с компакт-диска. В проекте RecordRead три кнопки соответствуют трем методам чтения (каждый из своего файла). Сначала рассмотрим первый метод — как делать ни в коем случае нельзя.

В проекте RecordWrite имеем следующий код (листинг 3.35).

type

 TMethod1Record = packed record

  Hour: Word;

  Minute: Word;

  Second: Word;

  MSec: Word;

  Msg: string;

 end;

procedure TForm1.Button1Click(Sender: TObject);

var

 Rec: TMethod1Record;

 Stream: TFileStream;

begin

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

 Rec.Msg := Edit1.Text;

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

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

 Stream.Free;

end;

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

procedure TForm1.Button1Click(Sender: TObject);

var

 Rec: TMethod1Record;

 Stream: TFileStream;

begin

 Stream := TFileStream.Create('Method1.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; { * }