Данная глава посвящена "подводным камням"— ситуациям, в которых ошибки или неожиданное поведение программы наиболее вероятны. Другими словами, подводные камни — это то, на чем раз за разом спотыкаются многие начинающие программисты. Не претендуя на описание всех подобных случаев, мы, тем не менее, разберем несколько достаточно характерных примеров. Более полный список можно посмотреть в разделе "Подводные камни" сайта "Королевство Delphi" (см. приложение 1).

Подводные камни можно классифицировать по причинам, вызывающим повышенную вероятность ошибок, следующим образом:

□ Аппаратные "камни" — проблемы, вызванные некорректной работой аппаратуры. Наиболее известная из таких проблем — неправильная работа операции деления в блоке FPU первых версий процессора Pentium (в настройках компилятора Delphi можно увидеть опцию Pentium-safe FDIV — при ее включении генерируется более медленный, но правильно работающий на (очень) старых процессорах код для вещественного деления). Но подобные проблемы, к счастью, редки, поэтому мы не будем рассматривать их здесь.

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

□ "Камни" компилятора — проблемы, вызванные ошибками компиляторе Delphi.

□ "Камни" VCL — ошибки, содержащиеся в библиотеке VCL. Ранее мы уже упоминали о некоторых из них. Далее мы рассмотрим еще несколько имеющихся в ней ошибок.

□ И последний класс "камней" — ошибки, связанные с тем, что программист — человек. Здесь объединены ситуации, когда документация даёт исчерпывающее описание проблемы, аппаратура и программные средства работают безукоризненно, но все новые и новые поколения программистов совершают одни и те же ошибки, потому что ситуация кажется им слишком простой и очевидной, чтобы изучать документацию. (Заметим, что это не говорит плохо о таких программистах — человеческая психология имеет свои законы, столь же объективные, как и законы в естественных науках.) Но компьютер — лишь имитация реального мира, и нередко он не оправдывает наших интуитивных ожиданий. Пункты приведенной классификации не являются взаимоисключающими: далее мы увидим, что некоторые ситуации попадают одновременно под несколько пунктов.

Данная глава посвящена детальному разбору некоторых из подобных ситуаций. Она состоит из четырех разделов. Первый раздел посвящен неочевидным проблемам при работе с целыми числами, второй — при работе с вещественными, в третьем описываются неочевидные моменты использования строк, а в четвертом собрана небольшая коллекция не связанных между собой "подводных камней", с которыми пришлось столкнуться автору книги. Всем ситуациям дано подробное объяснение, чтобы читатель не только запомнил, как делать нельзя, но и понял, почему.

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

Button1: TButton

Label1: TLabel

Button1.OnClick

Label1.Caption

Аппаратная реализация целочисленной арифметики достаточно очевидна и в большинстве случаев не приносит неожиданностей. К тому же возможные проблемы в том или ином виде упомянуты во многих книгах по Delphi, поэтому даже начинающий программист обычно готов к ним. В этом разделе мы компактно изложим эти проблемы и объясним причины их появления.

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

Примечание

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

Целые числа могут быть знаковыми и беззнаковыми. Сначала рассмотрим формат более простых беззнаковых чисел. Если у нас есть N двоичных разрядов для хранения такого числа, то мы можем представить любое число от 0 до 2^N-1. В Delphi беззнаковые целые представлены фундаментальными типами Byte (N=8, диапазон 0..255), Word (N=16, диапазон 0..65 535) и LongWord (N=32, диапазон 0..4 294 967 295).

Примечание

Фундаментальными называются те типы данных, разрядность которых не зависит от аппаратной платформы. Кроме них существуют еще общие (generic) типы, разрядность которых определяется разрядностью платформы. В Delphi это типы

Integer

(знаковое целое) и

Cardinal

(беззнаковое целое. В имеющейся реализации они имеют 32 разряда, но при переходе на 64-разрядные компиляторы следует ожидать что эти типы также станут 64-разрядными. В частности, в 16-разрядном Turbo Pascal тип

Integer

был 16-разрядным а типа

Cardinal

там не было).

Знаковые числа устроены несколько сложнее. Старший из N бит, отводящихся на такое число, служит для хранения знака (этот бит называется знаковым). Если этот бит равен нулю, число считается положительным, а оставшиеся N-1 разрядов используются для хранения числа так же, как в случае беззнакового целого (эти разряды мы будем называть беззнаковой частью). В этом случае знаковое число ничем не отличается от беззнакового. Отрицательные значения кодируются несколько сложнее. Когда все разряды (включая знаковый бит) равны единице, это соответствует значению -1. Рассмотрим это на примере однобайтного знакового числа. Числу -1 в данном случае соответствует комбинация 1 1111111 (знаковый бит мы будем отделять от остальных пробелом), т.е. беззнаковая часть числа содержит максимально возможное значение -127. Числу -2 соответствует комбинация 1 1111110, т.е. в беззнаковой части содержится 126. В общем случае отрицательное число, хранящееся в N разрядах равно X-2^N-1, где X — положительное число, хранящееся в беззнаковой части. Таким образом, N разрядов позволяют представить знаковое целое в диапазоне -2^N-1..2^N-1-1, причем значению -2^N-1 соответствует ситуация, когда все биты, кроме знакового равны нулю.

Такая на первый взгляд не очень удобная система позволяет унифицировать операции для знаковых и беззнаковых чисел. Для примера рассмотрим число 11111110. Если его рассматривать как беззнаковое, оно равно 254, если как знаковое, то -2. Вычитая из него, например, 3, мы должны получить 251 и -5 соответственно. Как нетрудно убедиться, в беззнаковой форме 251 — это 11111011. И число -5 в знаковой форме — это тоже 11111011, т.е. результирующее состояние разрядов зависит только от начального состояния этих разрядов и вычитаемого числа и не зависит от того, знаковое или беззнаковое число представляют эти разряды. И это утверждение справедливо не только для выбранных чисел, но и вообще для любых чисел, если ни они, ни результат операции не выходят за пределы допустимого диапазона. То же самое верно для операции сложения. Поэтому в системе команд процессора нет отдельно команд знакового и беззнакового сложения и вычитания — форматы чисел таковы, что можно обойтись одной парой команд (для умножения и деления это неверно, поэтому существуют отдельно команды знакового и беззнакового умножения и деления).

Ранее мы специально оговорили, что такое удобное правило действует только до тех пор, пока аргументы и результат остаются в рамках допустимого диапазона. Рассмотрим, что произойдет, если мы выйдем за его пределы. Пусть в беззнаковой записи нам нужно из 130 вычесть 10. 130 — это 10000010, после вычитания получим 01111000 (120). Но если попытаться интерпретировать эти двоичные значения как знаковые числа, получится, что из -126 мы вычитаем 10 и получаем 120. Такими парадоксальными результатами приходится расплачиваться за унификацию операций со знаковыми и беззнаковыми числами.

Рассмотрим другой пример: из пяти (в двоичном представлении 00000101) вычесть десять (00001010). Здесь уместно вспомнить вычитание в столбик, которое изучается в школе: если в разряде уменьшаемого стоит цифра, большая, чем в соответствующем разряде вычитаемого, то из старшего разряда уменьшаемого приходится занимать единицу. То же самое и здесь: чтобы вычесть большее число из меньшего, как бы занимается единица из несуществующего девятого разряда. Это можно представить так: из числа (1)00000101 вычитается (0)00001010 и получается (0)11111011 (несуществующий девятый разряд показан в скобках: после получения результата мы про него снова забываем). Если интерпретировать полученный результат как знаковое целое, то он равен -5, т.е. именно тому, что и должно быть. Но с точки зрения беззнаковой арифметики получается, что 5-10=251.

Приведенные примеры демонстрировали ситуации, когда результат укладывался в один из диапазонов (знаковый или беззнаковый), но не укладывался в другой. Рассмотрим, что будет, если результат не попадает ни в тот, ни в другой диапазон. Пусть нам нужно сложить 10000000 и 10000000. При таком сложении снова появляется несуществующий девятый разряд, но на этот раз из него единица не занимается, а в него переносится лишняя. Получается (1)00000000. Несуществующий разряд потом игнорируется. С точки зрения знаковой интерпретации получается, что 128 + 128 = 0. С точки зрения беззнаковой — что -128 + (-128) = 0, т.е. оба результата, как и можно было ожидать с самого начала, оказываются некорректными.

Знаковые целые представлены в Delphi типами

ShortInt

SmallInt

LongInt

Int64

Примечание

32-разрядные процессоры не могут выполнять операции непосредственно с 64-разрядными числами, поэтому компилятор генерирует код, который обрабатывает это число по частям. Сначала операция сложения или вычитания выполняется над младшими 32-мя разрядами а потом — над старшими 32-мя, причем, если в первой операции занималась единица из несуществующего (в рамках данной операции) 33-го разряда или единица переносилась в него, при второй операции эта единица учитывается.

Далее приведены несколько примеров, иллюстрирующих сказанное.

Начнем с рассмотрения простого примера (листинг 3.1. проект Assignment1 на компакт-диске).

procedure TForm1.Button1Click(Sender: TObject);

var

 X: Byte;

 Y: ShortInt;

begin

 Y := -1;

 X := Y;

 Label1.Caption := IntToStr(X);

end;

При выполнении этого примера будет выведено значение 255. Здесь мы сталкиваемся с тем, что все разряды значения

Y

X

Y

X

Примечание

Промежуточная переменная

Y

понадобилась потому, что прямо присвоить переменной значение, выходящее за ее диапазон, компилятор не позволит — возникнет ошибка компиляции "Constant expression violates subrange bounds".

Строго говоря, в Delphi предусмотрена защита от подобного присваивания. Если включить опцию Range checking (включается в окне Project/Options... на закладке Compiler или директивой компилятора

{$R+}

{$RANGECHECKS ON}

X := Y

ERangeError

В следующем примере (листинг 3.2, проект Assignment2 на компакт-диске) мы рассмотрим присваивание числу такого значения, которое не укладывается ни в знаковый, ни в беззнаковый диапазон.

procedure TForm1.Button1Click(Sender: TObject);

var

 X: Byte;

 Y: Word;

begin

 Y := 1618;

 X := Y;

 Label1.Caption := IntToStr(X)

end;

На экране появится число 82. Разберемся, почему это происходит. Число 1618 в двоичной записи равно 00000110 01010010. При присваивании этого значения переменной

X

Х

Разумеется, при включенной опции Range checking и в этом случае произойдет исключение

ERangeError

Приведенные примеры показывают два основных источника неожиданностей, возникающих при присваивании значения целой переменной:

1. При смешении знаковых и беззнаковых чисел значение меняется из-за того, что старший бит интерпретируется то как знак числа, то как старший разряд. 

2. При присваивании переменной значения, требующего большего числа разрядов, "лишние" разряды просто игнорируются.

Все проблемы при присваивании сводятся к одному из этих случаев или к их комбинации.

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

В некоторых случаях возможность присваивания значений, выходящих за пределы диапазона переменной, может быть необходимой (например, для реализации "хитрых" алгоритмов или при сопряжении сторонних библиотек, одна из которых использует знаковые типы, другая — беззнаковые). Чтобы включение

ERangeError

procedure TForm1.Button1Click(Sender: TObject);

var

 X: Byte;

 Y: ShortInt;

begin

 Y := -1;

 X := Byte(Y);

 Label1.Caption := IntToStr(X)

end;

В результате его выполнения переменная

X

Переполнением принято называть ситуацию, когда при операциях над переменной результат выходит за пределы ее диапазона. Рассмотрим следующий пример (листинг 3.4, проект Overflow1 на компакт-диске).

procedure TForm1.Button1Click(Sender: TObject);

var X: Byte;

begin

 X := 0;

 X := X - 1;

 Label1.Caption := IntToStr(X)

end;

Переменная

X

Немного изменим этот пример — заменим оператор вычитания функцией

Dec

{$R+}

procedure TForm1.Button1Click(Sender: TObject);

var X: Byte;

begin

 X := 0;

 Dec(X);

 Label1.Caption := IntToStr(X);

end;

Результат получается тот же (X получает значение 255), но обратите внимание: несмотря на то, что опция Range checking включена, исключение не возникает. Этим пример Overflow2 отличается от Overflow1 — там исключение возникнет. Связано это с тем, что переполнение при использовании

Dec

{$Q+}

{$OVERFLOWCHECKS ON}

EIntOverflow

Посмотрим, что произойдет, если мы попытаемся сравнить знаковое и беззнаковое число (листинг 3.6, пример Compare1 на компакт-диске).

procedure TForm1.Button1Click(Sender: TObject);

var

 X: Byte;

 Y: ShortInt;

begin

 Y := -1;

 X := Y;

 if X = Y then Label1.Caption := 'Равно';

 else Label1.Caption := 'He равно';

end;

В окне появится надпись Не равно, хотя последовательность битов в переменных

X

Y

X

Y

Те, кто успел самостоятельно откомпилировать пример Compare1, могли заметить предупреждение компилятора на строке со сравнением: "Comparing signed and unsigned types — widened both operands". Это предупреждение все объясняет: компилятор, зная, что совпадение наборов битов не гарантирует равенство знакового и беззнакового выражения, сначала "расширяет" типы выражений до того типа, чей диапазон целиком вмещает оба требуемых диапазона и лишь затем выполняет сравнение. Это обеспечивает правильный результат сравнения, но требует дополнительных ресурсов, поэтому компилятор выдает предупреждение.

Аналогичные действия компилятор выполнит при сравнении выражений типов

Word

SmallInt

LongInt

LongWord

Явное приведение типов позволяет избавиться от операций по расширению типа и ограничиться побитовым сравнением (листинг 3.7. пример Compare2 на компакт-диске).

procedure TForm1.Button1Click(Sender: TObject);

var

 X: Byte;

 Y: ShortInt;

begin

 Y := -1;

 X := Y;

 if X = Byte(Y) then Label1.Caption := 'Равно'

 else Label1.Caption := 'Не равно';

end;

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

Примечание

Операции >, <, >= и <= тоже работают по-разному для знаковых и беззнаковых чисел. Пусть, например, сравниваются числа 01000000 и 11000000. В беззнаковом формате это 64 и 192, поэтому первое число меньше второго. А в знаковом это 64 и -64, т. е. первое число больше. Из-за этого для операций сравнения для знаковых и беззнаковых чисел в системе команд процессора существуют разные команды. В литературе, чтобы подчеркнуть это, часто используются различные названия операций в зависимости от формата: для знаковых чисел — "больше" и "меньше", для беззнаковых — "выше" и "ниже".

Рассмотрим программу (пример ForRange на компакт-диске), на форме которой находятся кнопка и панель, причем кнопка (это важно!) — не на панели, а на форме, а на панели нет никаких компонентов. Обработчик нажатия на кнопку выглядит следующим образом (листинг 3.8).

procedure TForm1.Button1Click(Sender: TObject);

var

 I: Cardinal;

begin

 for I := 0 to Panel1.ControlCount - 1 do

  Panel1.Controls[I].Tag := 1;

end;

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

for

При нулевом количестве компонентов на панели выражение

Panel1.ControlCount - 1

Сardinal

Ошибка исчезнет, если тип переменной

I

Integer

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

Integer

Cardinal

Строго говоря, аналогичная проблема может возникнуть и со знаковыми типами, если границы цикла for переходят допустимый диапазон этих чисел, просто циклы, переменная которых принимает значения вблизи границ диапазона типа

Integer

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

Для начала — немного математики. В школе мы проходим два вида дробей простые и десятичные. Десятичные дроби, по сути дела, представляют собой разложение числа по степеням десяти. Так, запись 13,6704 означает число, равное 1·10¹ + 3·10⁰ + 6·10^-1 + 7·10^-2 + 0·10^-3 + 4·10^-4. Но внутреннее представление всех чисел в компьютере, в том числе и вещественных, не десятичное, а двоичное. Поэтому он использует двоичные дроби. Они во многом похожи на десятичные, но основанием степени у них служит двойка. Так, двоичная дробь 101.1101 — это 1·2² + 0·2¹ + 1·2⁰ + 1·2^-1 + 1·2^-2 + 0·2^-3 + 1·2^-4. В десятичном представлении это число равно 5,8125, в чем нетрудно убедиться с помощью любого калькулятора.

Теперь вспомним научный формат записи десятичного числа. Первым в этой записи идет знак числа (плюс или минус). Дальше идет так называемая мантисса (число от 1 до 10). Затем идет экспонента (степень десяти, на которую надо умножить мантиссу, чтобы получить нужное число). Итак, уже упоминавшееся число 13,6704 запишется в этом формате как 1.36704·10¹ (или 1.36704E1 по принятым в компьютере правилам). Если записываемое число меньше единицы, экспонента будет отрицательной. Аналогичная запись существует и в двоичной системе. Так, 101.1101 запишется в виде 1.011101*10¹⁰ (везде использована двоичная форма записи, так что 10¹⁰ означает 2²). Именно такое представление реализовано в компьютере. Двоичная точка в такой записи не остается на одном месте, а сдвигается на величину, указанную в экспоненте, поэтому такие числа называются числами с плавающей точкой (floating point numbers).

В Delphi существует четыре вещественных типа:

Single

Double

Extended

Real

Знак — это всегда один бит. Он равен нулю для положительных чисел и единице для отрицательных. Что же касается размеров мантиссы и экспоненты, то именно в них и заключается различие между типами.

Прежде чем перейти к конкретным цифрам, рассмотрим подробнее тип

Real

Real

Real

а) общий вид вещественного числа

б) Двоичное представление числа типа Single

Рис. 3.1. Хранение вещественного числа в памяти

Микропроцессор Intel 8086/88 и его улучшенные варианты — 80286 и 80386 — также не имели аппаратной поддержки вещественных чисел. Но у систем на базе этих процессоров была возможность подключения так называемого сопроцессора. Эта микросхема работала с памятью через шины основного процессора и обеспечивала аппаратную поддержку вещественных чисел. В системах средней руки гнездо сопроцессора обычно было пустым, т.к. это уменьшало цену (разумеется, вставить туда сопроцессор не было проблемой). Для каждого центрального процессора выпускались свои сопроцессоры, маркировавшиеся Intel 8087, 80287 и 80387 соответственно. Были даже сопроцессоры, выпускаемые другими фирмами. Они работали быстрее, чем сопроцессоры Intel, но появлялись на рынке позже. Тип вещественных чисел, поддерживаемый сопроцессорами, не совпадает с

Real

Чтобы обеспечить в своих системах поддержку типов IEEE, Borland вводит в Turbo Pascal типы

Single

Double

Extended

Extended

Single

Double

Single

Double

Extended

Extended

Single

Double

Real

Real

Real

Extended

Real

Real

Начиная с 486-й серии Intel берет курс на интеграцию процессора и сопроцессора в одной микросхеме. Процент брака в микросхемах слишком велик, поэтому Intel идет на хитрость: если у микросхемы брак только в сопроцессорной части, то на этом кристалле прожигаются перемычки, блокирующие сопроцессор, и микросхема продается как процессор 80486SX, не имеющий встроенного сопроцессора (в отличие от полноценной версии, которую назвали 80486DX). Бывали и обратные ситуации, когда сопроцессор повреждений не имел, зато процессор был неработоспособен. Такие микросхемы превращали в "сопроцессор 80487". Но это уже из области экзотики, и, по имеющейся у нас информации, до России такой сопроцессор не дошел.

Процессор Pentium во всех своих вариантах имел встроенный блок вычислений с плавающей точкой (FPU — Floating Point Unit), и отдельный сопроцессор ему не требовался. Таким образом, с приходом этого процессора тип

Real

Single

Double

Extended

Real

Double

Real48

Здесь и далее под словом

Real

Существует директива компилятора

{$REALCOMPATIBILITY ON/OFF}

Real

Real48

Double

Размеры полей для различных вещественных типов указаны в табл. 3.1.

Таблица 3.1. Размеры полей в вещественных типах

Другие параметры вещественных типов, такие как диапазон и точность, можно найти в справке Delphi.

Рассмотрим тип

Single

Single

Экспонента — по определению всегда целое число. Но способ записи экспоненты в вещественных числах не совпадает с рассмотренным ранее способом записи чисел со знаком. Ноль в этом представлении записывается как 01111111 (в обычном представлении это равно 127). Соответственно. 10000000 (128 в обычном представлении) означает единицу, а 01111110 (126) означает -1, и т. д. (т.е. из обычного беззнакового числа надо вычесть 127, и получится число, закодированное в экспоненте). Такая запись чиста называется нормализованной. 

Из описанных правил есть исключения. Так, если все биты экспоненты равны нулю (т.е. там стоит число -127), то к мантиссе перед ее началом надо добавлять не "1.", а "0." (денормализованная запись). Это позволяет увеличить диапазон вещественных чисел. Если бы этого исключения не было, то минимально возможное положительное число типа

Single

INF

NAN

NAN

INF

Для задания нуля все биты мантиссы и экспоненты должны быть равны нулю (формально это означает 0·10^-127). С учетом описанных правил, если хотя бы один бит экспоненты не будет равен нулю (т.е. экспонента будет больше -127), запись будет считаться нормализованной, и нулевая мантисса будет рассматриваться как единица. Поэтому никакие другие комбинации значений мантиссы и экспоненты не могут дать ноль.

Тип

Double

Несколько иначе устроен

Extended

Single

Float

Single

Double

Extended

Тип

Real

Real

Ранее мы отметили, что FPU всегда выполняет все операции в формате

Extended

У FPU существует специальный двухбайтный регистр, называемый управляющим словом. Установка отдельных битов этого регистра диктует то или иное поведение при выполнении операций. Прежде всего, это связано с тем, какие исключения может возбуждать FPU. Другие биты этого регистра отвечают за то, как будут округляться числа, как FPU понимает бесконечность, — всё это можно при необходимости узнать из документации Intel. Нас же будут интересовать только два бита из этого слова: восьмой и девятый. Именно они определяют, как будут обрабатываться числа внутри сопроцессора.

Если восьмой бит содержит единицу (так установлено по умолчанию), то десять байтов внутренних регистров сопроцессора будут задействованы полностью, и мы получим "полноценный"

Extended

Double

Single

Extended

Для работы с управляющим словом сопроцессора в модуле

System

Default8087CW

Word

Set8087CW(CW: Word)

Default8087CW

записывается

Set8087CW

Default8087CW

Такое поведение этой функции не всегда удобно — иногда бывает нужно сохранить старое значение переменной

Default8087CW

Set8087CW

Default8087CW

Get8087CW

Default8087CW

Итак, установить значение управляющего слова можно с помощью команды

FLDCW

FNSTCW

Word

asm

 FNSTCW MyCW

 AND MyCW, 0FC00h

 OR MyCW, 200h

 FLDCW MyCW

end;

Начиная с Delphi 6, в модуле

Math

SetPrecisionMode

pmSingle

pmDouble

pmExtended

Из школы мы все помним, что не каждое число может быть записано конечной десятичной дробью. Бесконечные дроби бывают двух видов: периодичные и непериодичные. Примером непериодичной дроби является число π, периодичной — число ⅓ или любая другая простая дробь, не представимая в виде конечной десятичной дроби.

Примечание

Напомним, что периодичные дроби — это такие дроби которые содержат бесконечно повторяющуюся последовательность цифр. Например, 1/9=0,11111..., 1/12=0,08333333..., 1/7=0,142857142857... Такие числа записывают со скобками — в них заключают повторяющуюся часть. Те же числа должны быть записаны так: 1/9=0,1(1), 1/12=0,08(3), 1/7=0,1(428571)

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

До сих пор мы говорили только о десятичных бесконечных дробях. Но двоичные дроби тоже могут быть бесконечными. Даже более того, любое число, выражаемое конечной двоичной дробью, может быть также выражено и десятичной конечной дробью. Но существуют числа (например, 1/5), которые выражаются конечной десятичной дробью, но не могут быть выражены конечной двоичной дробью. Это и есть наиболее важное отличие аппаратной реализации вещественных чисел от наших интуитивных представлений. Теперь у нас достаточно теоретических знаний, чтобы перейти к рассмотрению конкретных примеров — "подводных камней", приготовленных вещественными числами.

Самый первый "подводный камень", на котором спотыкаются новички — это то, что вещественная переменная может получить не совсем то значение, которое ей присвоено. Рассмотрим это на простом примере (листинг 3.9, примеp WrongValue на компакт-диске).

procedure TForm1.Button1Click(Sender: TObject);

var

 R: Single;

begin

 R := 0.1;

 Label1.Caption = FloatToStr(F);

end;

Что мы увидим, когда нажмем кнопку? Разумеется, не 0.1, иначе не было бы смысла писать этот пример. Мы увидим 0.100000001490116, т.е. расхождение в девятой значащей цифре. Из справки по Delphi мы знаем, что точность типа Single — 7–8 десятичных разряда, так что нас, по крайнем мере, никто не обманывает. В чем же причина? Просто число 0,1 не представимо в виде конечной двоичной дроби, оно равно 0,0(0011). И эта бесконечная двоичная дробь обрубается на 24-х знаках; мы получаем не 0,1, а некоторое приближенное число (какое именно — см. выше). А если мы присвоим переменной R не 0.1, а 0.5? Тогда мы получим на экране 0.5, потому что 0.5 предоставляется в виде конечной двоичной дроби. Немного поэкспериментировав с различными числами, мы заметим, что точно представляются те числа, которые выражаются в виде m/2n, где m, n — некоторые целые числа (разумеется, n не должно превышать 24, а то нам не хватит точности типа

Single

Single

Если в этом примере изменить тип переменной

R

Single

Double

Extended

FloatToStr

Теперь попробуем сравнить значение переменной и константы, которую мы ей присвоили (листинг 3.10, пример Compare1 на компакт-диске).

procedure TForm1.Button1Click(Sender: TObject);

var

 R: Single;

begin

R := 0.1;

 if R = 0.1 then Label1.Caption := 'Равно'

 else Label1.Caption := 'He равно';

end;

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

R

Extended

R

Extended

Single

Extended

Extended

Single

Из-за таких хитрых преобразований оказывается, что мы сравниваем два близких, но все же не равных числа. Отсюда — закономерный результат в виде надписи Не равно.

Тут уместна аналогия с десятичными дробями. Допустим, в одном случае мы делим 1 на три с точностью до трех знаков и получаем 0,333. Потом мы делим 1 на три с точностью до четырех знаков и получаем 0,3333. Теперь мы хотим сравнить эти два числа. Для этого приводим их к точности в четыре разряда. Получается, что мы сравниваем 0,3330 и 0,3333. Очевидно, что это разные числа.

Если попробовать заменить число 0,1 на 0,5, то мы увидим надпись Равно. Полагаем, что читатели уже догадались, почему, но все же приведем объяснение. Число 0,5 — это конечная двоичная дробь. При прямом приведении ее к типу

Extended

Single

Extended

Теперь попытаемся сравнить переменную не с константой, а с другой переменной (листинг 3.11, пример Compare2 на компакт-диске).

procedure TForm1.Button1Click(Sender: TObject);

var

 R1: Single;

 R2: Double;

begin

 R1 := 0.1;

 R2 := 0.1;

 if R1 = R2 then Label1.Caption := 'Равно'

 else Label1.Caption := 'He равно';

end;

Почему этот пример также выдаст Не равно, понять проще, чем в предыдущем случае. При

R1

R2

Single

R2

Как и в предыдущем случае, замена 0,1 на 0,5 даст результат Равно.

Рассмотрим еще один пример, иллюстрирующий ситуацию, которая часто озадачивает начинающего программиста (листинг 3.12, пример Subtraction на компакт-диске).

procedure TForm1.Button1Click(Sender: TObject);

var

 R: Single;

 I: Integer;

begin

 R := 1;

 for I := 1 to 10 do R := R - 0.1;

 Label1.Caption := FloatToStr(R);

end;

В результате выполнения этого кода на экране появится -7.3015691270939E-8 вместо ожидаемого нуля. Объяснение этому достаточно очевидно, если вспомнить то, о чем мы говорили ранее. Число 0,1 не может быть передано точно ни в одном из вещественных типов, а при каждом вычислении происходит преобразование

Single

Extended

Изменим в предыдущем примере тип переменной

R

Single

Double

Double

Single

А теперь — вопрос на засыпку. Изменится ли результат, если мы заменим

Double

Extended

Double

Extended 

Все дело в использовании "неполноценного"

Extended

Extended

Set8080CW(Get8087CW or $0100)

Примечание

В версиях Delphi по 5-ю включительно, где отсутствует функция

Get8087CW

, можно использовать такую конструкцию :

Set8087CW(Default8087CW)

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

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

Set8087CW(Get8087CW and $FCFF or $0200)

Extended

Set8087CW(Get8087CW and $FCFF)

Заметим, что при загрузке в 10-байтный регистр сопроцессора числа типа

Extended

В том, что описанная проблема с потерей точности встречается все реже, есть заслуга и разработчиков VCL. Зная, вызовы каких функций могут привести к изменению управляющего слова FPU, они перед этими вызовами запоминают управляющее слово, а затем восстанавливают. В более поздних версиях Delphi количество таких "оберток" больше, чем в ранних, поэтому чем новее версия Delphi, тем меньше шанс столкнуться с описанной проблемой. Здесь мы рассмотрим несколько примеров из исходного кода стандартных модулей Delphi 2007.

Для динамической загрузки DLL предназначена API-функция

LoadLibrary

SysUtils

SafeLoadLibrary

{ SafeLoadLibrary calls LoadLibrary, disabling normal Win32 error message popup dialogs if the requested file can't be loaded. SafeLoadLibrary also preserves the current FPU control word (precision, exception masks) across the LoadLibrary call (in case the DLL you're loading hammers the FPU control word in its initialization, as many MS DLLs do) }

function SafeLoadLibrary(const Filename: string; ErrorMode: UINT): HMODULE;

var

 OldMode: UINT;

 FPUControlWord: Word;

begin

 OldMode := SetErrorMode(ErrorMode);

 try

  asm

   FNSTCW FPUControlWord

  end;

  try

   Result := LoadLibrary(PChar(Filename));

  finally

   asm

    FNCLEX

    FLDCW FPUControlWord

   end;

  end;

 finally

  SetErrorMode(OldMode);

 end;

end;

Как видно из комментария, проблема в том, что многие системные библиотеки изменяют управляющее слово FPU при своей инициализации.

В функции

CreateADOObject

ADODB

function CreateADOObject(const ClassID: TGUID): IUnknown;

var

 Status: HResult;

 FPUControlWord: Word;

begin

 asm

  FNSTCW FPUControlWord

 end;

 Status :=

  CoCreateInstance(ClassID, nil, CLSTX_INPROC_SERVER or CLSCTX_LOCAL_SERVER, IUnknown, Result);

 asm

  FNCLEX

  FLDCW FPUControlWord

 end;

 if (Status = REGDB_E_CLASSNOTREG) then

  raise Exception.CreateRes(@SADOCreateError)

 else OleCheck(Status);

end;

Здесь восстанавливать управляющее слово приходится после вызова системной функции

CoCreateInstance

CoCreateInstance

Аналогичную защиту можно обнаружить в модуле

Dialogs

TCommonDialog.TaskModalDialog

В модуле

Windows

CreateWindow

CreateWindowEx

CreateWindowEx

function _CreateWindowEx(dwExStyle: WORD; lpClassName: PChar; lpWindowName: PChar; dwStyle: DWORD; X, Y, nWidth, nHeight: Integer; hWndParent: HWND; hMenu: HMENU; hInstance: HINST; lpParam: Pointer): HWND; stdcall; external user32 name 'CreateWindowExA';

function CreateWindowEx(dwExStyle: DWORD; lpClassName: PChar; lpWindowName: PChar; dwStyle: DWORD; X, Y, nWidth, nHeight: Integer; hWndParent: HWND; hMenu: HMENU; hInstance: HINST; lpParam: Pointer): HWND;

var

 FPUCW: Word;

begin

 FPUCW := Get8087CW;

 Result :=

  _CreateWindowEx(dwExStyle, lpClassName, lpWindowName,

  dwStyle, X, Y, nWidth, nHeight, hWndParent, hMenu,

  hInstance, lpParam);

 Set8087CW(FPUCW);

end;

Модуль

Windows

CreateWindowExA

CreateWindowEx

CreateWindowExA

CreateWindowExA

CreateWindowEx

Примечание

В модуле

Windows

можно обнаружить еще одну интересную деталь: функции

CreateWindowA

и

CreateWindowW

из библиотеки user32.dll этим модулем вообще не импортируются. Вместо этого одноименные обертки вызывают импортированные функции

_CreateWindowExA

и

_CreateWindowExW

, передавая им 0 в качестве значения параметра

dwExStyle

.

Когда мы имеем дело с вычислениями с ограниченной точностью, возникает такой парадокс. Пусть, например, мы считаем с точностью до трех значащих цифр. Прибавим к числу 1,00 число 1,00·10^-4. Если бы все было честно, мы получили бы 1,0001. Но у нас ограничена точность, поэтому мы вынуждены округлять до трех значащих цифр. В результате получается 1,00. Другими словами, к некоторому числу мы прибавляем другое число, большее нуля, а в результате из-за ограниченной точности мы получаем то же самое число. Наименьшее положительное число, которое при добавлении его к единице дает результат, не равный единице, называется машинным эпсилон.

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

Прежде чем искать машинное эпсилон программно, попытаемся найти его из теоретических соображений. Итак, мантисса типа

Extended

Листинг 3.16 показывает, как можно найти это число (пример Epsilon на компакт-диске).

procedure TForm1.Button1Click(Sender: TObject);

var

 R: Extended;

 I: Integer;

begin

 R := 1;

 while 1 + R/2 > 1 do R := R / 2;

 Label1.Caption := FloatToStr(R);

end;

Запустив этот код, мы получим на экране 1.0842021724855Е-19 в полном соответствии с нашими теоретическими выкладками.

Примечание

В тех системах, где наблюдается описанная проблема с уменьшением точности, программа выдаст 2.22044604925031Е-16. Если вы увидели у себя это число, добавьте код, который переведет FPU в режим максимальной точности.

А теперь изменим тип переменной

R

Extended

Double

Single

1 + R / 2 > 1

Extended

R

Extended

Extended

Double

R

Single

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

□ Если ваша задача — просто получить "красивое" представление числа на экране, то функцию

FloatToStr

FloatToStrF

Format

□ Сравнение вещественных чисел следует выполнять с учетом погрешности, т.е. вместо

if а = b

if Abs(а - b) < Ерs

Eps

SameValue

if SameValue(a, b, Eps)

□ Для денежных расчетов следует выбирать тип

Currency

RoundTo

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

Для работы с кодировкой ANSI в Delphi существует три вида строк:

AnsiString

ShortString

PChar

string

AnsiString

ShortString

{$H+/-}

{$LONGSTRINGS ON/OFF}

string

ShortString

string[255]

Рис. 3.2. Устройство различных строковых типов Delphi

Наиболее просто устроен тип

ShortString

ShortString

Ограничения типа

ShortString

ShortString

В системе приняты так называемые нуль-терминированные строки: строка передается указателем на ее первый символ, длина строки отдельно нигде не хранится, признаком конца строки считается встретившийся в цепочке символов

#0

PChar

PChar = ^Сhar

PChar

P

PChar

P[N]

N

ShortString

PChar

Inc

и

PChar

При работе с

PChar

AnsiString

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

StrNew

StrDispose

StrDispose

#0

Компилятор также позволяет рассматривать статические массивы типа

Char

PChar

Тип

AnsiString

ShortString

PChar

#0

AnsiString

Переменная типа

AnsiString

PChar

AnsiString

ShortString

Счетчик ссылок позволяет реализовать то, что называется copy-on-demand, копирование по необходимости. Если у нас есть две переменные

S1

S2

AnsiString

S1 := S2

S1

S2

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

Литералами называются значения, записываемые в программе буквально. В частности, строковые литералы в Delphi — это последовательности символов, заключенных в кавычки или записанных в виде ANSI-кодов с использованием префикса

#

Когда в программе встречается строковый литерал, компилятор должен поместить его в какую-либо область памяти, чтобы это значение стало доступным программе. Компилятор Delphi размещает строковые литералы в сегменте кода, в участках, управление которым никогда не передается. В данном разделе мы рассмотрим, к каким последствиям это может привести.

Положим на форму пять кнопок и напишем следующие обработчики для нажатия на них (листинг 3.17, пример Constants на компакт-диске).

procedure TForm1.Button1Click(Sender: TObject);

var

 P: PChar;

begin

 P := 'Xest';

 P[0] := 'T'; { * }

 Label1.Caption := P;

end;

procedure TForm1.Buttom2Click(Sender: TObject);

var

 S: string;

 P: PChar;

begin

 S:= 'Xest';

 P := PChar(S);

 P[0] := 'T'; { * }

 Label1.Caption := P;

end;

procedure TForm1.Button3Click(Sender: TObject);

var

 S: string;

begin

 S := 'Xest';

 S[1] := 'T';

 Label1.Caption := S;

end;

procedure TForm1.Button4Click(Sender: TObject);

var

 S: ShortString;

begin

 S := 'Xest';

 S[1] := 'T';

 Label1.Caption := S;

end;

procedure TForm1.Button5Click(Sender: TObject);

var

 S: ShortString;

 P: PChar;

begin

 S := 'Xest';

 P := @S[1];

 P[0] := 'T';

 Label1.Caption := P;

end;

В этом примере только нажатие на третью и четвертую кнопку приводит к появлению надписи Test. Первые два обработчика вызывают исключение Access violation в строках, отмеченных звездочками, а при нажатии пятой кнопки программа обычно работает без исключении (хотя в некоторых случаях оно все же может возникнуть), но к слову "Test" добавляется какой-то мусор. Разберемся, почему так происходит.

Встретив в первом обработчике литерал

'Xest'

PChar

P

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

AnsiString

S

PChar

P

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

S

В четвертом случае литерал также хранится в сегменте кода, но работы с указателем уже нет. Этот литерал занимает там пять байтов: один байт на длину и четыре — на символы. Переменная

S

В пятом случае мы получаем указатель на этот участок стека. Обратите внимание, что приведение типов в данном случае не работает: для записи в

P

@

PChar

AnsiString

PChar

поскольку

#0

Общий вывод таков: пока мы не вмешиваемся в работу компилятора с типами

ShortString

AnsiString

PChar

PChar

В разд. 1.1.13 мы уже говорили, что когда у функции есть параметр типа

PChar

В примерах кода, приведенных на различных сайтах, можно нередко встретить такую ситуацию, когда литерал, передаваемый в качестве параметра типа

PChar

PCharLit

procedure TForm1.Button1Click(Sender: TObject);

begin

 Application.MessageBox('Text', nil, 0);

end;

procedure TForm1.Button2Click(Sender: TObject);

begin

 Application.MessageBox('A', nil, 0);

end;

procedure TForm1.Button3Click(Sender: TObject);

begin

 Application.MessageBox(PChar('Text'), nil, 0);

end;

procedure TForm1.Button4Click(Sender: TObject);

begin

 Application.MessageBox(PChar('A'), nil, 0);

end;

Метод

TApplication.MessageBox

PChar

string

nil

PChar

Происходит это потому, что тип литерала зависит не только от его вида, но и оттого, в каком контексте он упомянут. Например, в предыдущем разделе мы видели, что литерал

'Xest'

string

PChar

'Text'

'А'

PChar

PChar

PChar

PChar

'А'

Char

#0

Char

PChar

Итак, мы увидели, что явное приведение литерала к типу

PChar

PChar

PChar

Для типов

PChar

AnsiString

AnsiString

Начнем со сравнения двух строк типа

PChar

procedure TForm1.Button1Click(Sender: TObject);

var

 P1, P2: PChar;

begin

 P1 := StrNew('Test');

 P2 := StrNew('Test');

 if P1 = P2 then Label1.Caption := 'Равно';

 else Label1.Caption := 'Не равно';

 StrDispose(P1);

 StrDispose(P2);

end;

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

StrComp

procedure TForm1.Button2Click(Sender: TObject);

var

 P1, P2: PChar;

begin

 P1 := 'Test';

 P2 := 'Test';

 if P1 = P2 then Label1.Caption := 'Равно'

 else Label1.Caption := 'Не равно';

end;

Разница только в том, что строки хранятся не в динамической памяти, a в сегменте кода. Тем не менее на экране появится надпись Равно. Это происходит, разумеется, не потому, что сравнивается содержимое строк, а потому, что в данном случае два указателя оказываются равными. Компилятор поступает достаточно интеллектуально: видя, что в разных местах указаны литералы с одинаковым значением, он выделяет для такого литерала место только один раз, а потом помещает в разные указатели один адрес. Поэтому сравнение дает правильный (с интуитивной точки зрения) результат.

Такое положение дел только запутывает ситуацию со сравнением

PChar

PChar

Раз уж мы столкнулись с такой особенностью компилятора, немного отвлечемся от сравнения строк и "копнем" этот вопрос немного глубже. В частности, выясним, распространяется ли "интеллект" компилятора на литералы типа

AnsiString

procedure TForm1.Button3Click(Sender: TObject);

var

 S1, S2: string;

begin

 S1 := 'Test';

 S2 := 'Test';

 if Pointer(S1) = Pointer(S2) then Label1.Caption := 'Равно'

 else Label1.Caption := 'He равно';

end;

В этом примере на экран будет выведено Равно. Как мы видим, указатели равны, т.е. и здесь компилятор проявил "интеллект". 

Рассмотрим чуть более сложный случай (листинг 3.22).

procedure TForm1.Button4Click(Sender: TObject);

var

 P: PChar;

 S: string;

var

 S := 'Test';

 P := 'Test';

 if Pointer(S) = P then Label1.Caption := 'Равно'

 else Label1.Caption := 'He равно';

end;

В этом случае указатели окажутся не равны. Действительно, с формальной точки зрения литерал типа

AnsiString

PChar

#0

var

 GS1, GS2: string;

procedure TForm1.Button5Click(Sender: TObject);

begin

 GS1 := 'Test';

 GS2 := 'Test';

 if Pointer(GS1) = Pointer(GS2) then Label1.Caption := 'Равно';

 else Label1.Caption := 'Не равно';

end;

Этот пример отличается от приведенного в листинге 3.21 только тем, что теперь переменные глобальные, а не локальные. Однако этого достаточно, чтобы результат оказался другим — на экране мы увидим надпись Не равно. Для глобальных переменных компилятор всегда создаст уникальный литерал, на обнаружение одинаковых литералов ему "интеллекта" не хватает. Более того, если поставить точки останова в методах

Button3Click

Button4Click

S

Button4Click

S1

S2

Button3Click

AnsiString

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

PChar

var

 GP1, GP2: PChar;

procedure TForm1.Button6Click(Sender: TObject);

begin

 GP1 := 'Test';

 GP2 := 'Test';

 if GP1 = GP2 then Label1.Caption := 'Равно'

 else Label1.Caption := 'He равно';

end;

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

PChar

AnsiString

Но вернемся к сравнению строк. Как мы знаем, строки

AnsiString

PChar

AnsiString

PChar

procedure TForm1.Button7Click(Sender: TObject);

var

 P: PChar;

 S: string;

begin

 S := 'Test';

 P := 'Тest';

 it S = Р then Label1.Caption := 'Равно'

 else Label1.Caption := 'Не равно';

end;

Этот код выдаст Равно. Как мы знаем из предыдущих примеров (см. листинг 3.22), значения указателей не будут равны, следовательно, производится сравнение по содержанию, т.е. именно то, что к требуется. Если исследовать код, который генерирует компилятор, то можно увидеть, что сначала неявно создается строка

AnsiString

PChar

AnsiString

Для строк

ShortString

1. Литералы типа

ShortString

2. При сравнении строк

ShortString

AnsiString

AnsiString

3. При сравнении строк

ShortString

PChar

PChar

ShortString

Последнее правило таит в себе «подводный камень», который иллюстрируется следующим примером (листинг 3.26).

procedure TForm1.Button8Click(Sender: TObject);

var

 P: PChar;

 S: ShortString

begin

 P := StrAlloc(300);

 FillChar(P^, 299, 'A');

 P[299] := #0;

 S[0] := #255;

 FillChar(S[1], 255, 'A');

 if S = P then Label1.Caption := 'Равно'

 else Label1.Caption := 'Не равно';

 StrDispose(Р);

end;

Здесь формируется строка типа

PChar

ShortString

Происходит это вот почему: строка

PChar

ShortString

ShortString

ShortString

PChar

ShortString

Избежать этой ошибки поможет либо явное сравнение длины перед сравнением строк, либо приведение одной из сравниваемых строк к типу

AnsiString

procedure TForm1.Button9Click(Sender: TObject);

var

 P: PChar;

 S: ShortString;

begin

 P := StrAlloc(300);

 FillChar(P^, 299, 'A');

 P[299] := #0;

 S[0] := #255;

 FillChar(S[1], 255, 'A');

 if string(S) = P then Label1.Caption := 'Равно'

 else Label1.Caption := 'He равно';

 StrDispose(P);

end;

Учтите, что конвертирование в

AnsiString

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

AnsiString

PChar

procedure TForm1.Button10Click(Sender: TObject);

var

 S: string;

 P: PChar;

begin

 S := 'Test';

 P := PChar(S);

 if Pointer(S) = P then Label1.Caption := 'Равно'

 else Label1.Caption := 'Не равно';

end;

Вполне ожидаемый результат — Равно. Можно, например, перенести строку из сегмента кода в динамическую память с помощью

UniqueString

procedure TForm1.Button11Click(Sender: TObject);

var

 S: string;

 P: PChar;

begin

 S := '';

 P := PChar(S);

 if Pointer(S) = P then Label1.Caption : = 'Равно'

 else Label1.Caption := 'He равно';

end;

От предыдущего он отличается только тем, что строка

S

AnsiString

PChar

_LStrToPChar

Значение

''

AnsiString

nil

PChar

#0

_LStrToPChar

nil

#0

PChar(S) <> Pointer(S)

AnsiString

Из-за того, что две одинаковые строки

AnsiString

procedure TForm1.Button1Click(Sender: TObject);

var

 S1, S2: string;

 P: PChar;

begin

 S1 := 'Test';

 UniqueString(S1);

 S2 := S1;

 P := PChar(S1);

 P[0] := 'F';

 Label1.Caption := S2;

end;

В этом примере требует комментариев процедура

UniqueString

S1

В результате работы этого примера на экран будет выведено не Test, a Fest, хотя значение

S2

S1

S2 := S1

S1

S2

S2

S2

PChar

S1

S2

В данном примере все достаточно очевидно, но в более сложных случаях разработчик программы может и не подозревать, что строка, с которой он работает, разделяется несколькими переменными. Справка Delphi советует сначала обеспечить уникальность копии строки с помощью

UniqueString

PChar

Рассмотрим еще один пример, практически не отличающийся от предыдущего (листинг 3.31).

procedure TForm1.Button2Click(Sender: TObject);

var

 S1, S2: string;

 P: PChar;

begin

 S1 := 'Test';

 UniqueString(S1);

 S2 := S1;

 P := @S1[1];

 P[0] := 'F';

 Label1.Caption := S2;

end;

В этом случае на экран будет выведено Test, т.е. побочного изменения переменной не произойдёт, хотя переменная

S1

Вся разница между двумя примерами заключается в том, как получается указатель на строку. В первом примере он является результатом приведения типа строки к

PChar

UniqueString

S1

S2

S1

S2

Неявный вызов

UniqueString

UniqueString

UniqueString

AnsiString

Pointer

PChar

_LStrToPChar

UniqueString

Примечание

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

Хотя символ

#0

AnsiString

#0

PChar

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

#0

#0

AnsiString

PChar

#0

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

Описанные проблемы заставляют очень осторожно относиться к возможному появлению символа

#0

AnsiString

Очень интересный "подводный камень", связанный с типом

AnsiString

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

Edit1

В проекте 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; { * }

end;

Примечание

В проекте RecordRead объявлена такая же запись

TMethod1Record

, описание которой во втором случае для краткости опущено.

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

Msg

nil

Самый простой способ исправить ситуацию— изменить тип поля

Msg

ShortString

ShortString

ShortString

ShortString

С одним из этих недостатков можно бороться: если заменить в записи

ShortString

Char

В проекте RecordWrite этому соответствует код (листинг 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).

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)

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).

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

.

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

Ранее мы говорили о том, что копирование записей, содержащих поля типа

AnsiString

type

 TSomeRecord = record

  SomeField: Integer;

  Str: string;

 end;

procedure TForm1.Button1Click(Sender: TObject);

var

 Rec: TSomeRecord;

 S: string;

 procedure CopyRecord;

 var

  LocalRec: TSomeRecord;

 begin

  LocalRec.SomeField := 10;

  LocalRec.Str := 'Hello!!!';

  UniqueString(LocalRec.Str);

  Move(LocalRec, Rec, SizeOf(TSomeRecord));

 end;

begin

 CopyRecord;

 S := 'Good bye';

 UniqueString(S);

 Label1.Caption := Rec.Str;

 Pointer(Rec.Str) := nil;

end;

На экране вместо ожидаемого Hello!!! появится Good bye. Это происходит вот почему: процедура

Move

CopyRecord

Rec.Str

S

LocalRec.Str

Rec.Str

Обратите внимание на последнюю строку — приведение

Rec.Str

Pointer

Rec.Str

Чтобы показать, насколько коварна эта ошибка, рассмотрим следующий код (листинг 3.42, из того же примера RecordCopy на компакт-диске). 

procedure TForm1.Button2Click(Sender: TObject);

var

 Rec: TSomeRecord;

 S: string;

 procedure CopyRecord;

 var

  LocalRec: TSomeRecord;

 begin

  LocalRec.SomeField := 10;

  LocalRec.Str := 'Привет!';

  Move(LocalRec, Rec, SizeOf(TSomeRecord));

 end;

begin

 CopyRecord; S := 'Пока!';

 Label1.Caption := Rec.Str;

end;

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

UniqueString

Продолжим наши эксперименты. Запустим пример RecordCopy и понажимаем попеременно кнопки

Button1

Button2

Модифицируем код в локальной процедуре обработчика

Button1Click

Button1

Button2

Button1

Button1

TLabel

Rec.Str

Label1.Caption

Примечание

Если увеличить длину строки "Привет!" хотя бы на один символ, чтобы она была не короче, чем "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

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

Итак, создаем новую динамически компонуемую библиотеку (DLL). 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

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

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

System

System

AnsiString

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

ShareMem

SetMemoryManager

New

GetMem

ShareMem

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

ShareMem

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

ShareMem

FastMM

ShareMem

FastMM

ShareMem

FastMM

FastMM

Тот вариант

FastMM

ShareMem

SimpleShareMem

SimpleShareMem

ShareMem

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

AnsiString

PChar

ShareMem

StrNew

StrDispose

PChar

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

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

GetString

nil

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

const

 StatBufSize = ...; // Размер, подходящий для данного случая

var

 StatBuf: array[0..StatBufSize - 1] of Char;

 Buf: PChar;

 RealLen: Integer;

begin

 // Пытаемся разместить строку в буфере StatBuf

 RealLen := GetString(StatBuf, StatBufSize);

 if RealLen > StatBufSize then

 begin

  // Если StatBuf оказался слишком мал, динамически выделяем буфер

  // нужного размера и вызываем функции еще раз

  Buf := StrAlloc(RealLen);

  GetString(Buf, RealLen);

 end

 else

  // Размера статического буфера хватило. Пусть Buf указывает

  // на StatBuf, чтобы нижеследующий код мог в любом случае

  // обращаться к буферу через переменную Buf

  Buf := StatBuf;

 // Что-то делаем с содержимым буфера

 ...

 // Если выделяли память, ее следует очистить

 if Buf <> StatBuf then StrDispose(Buf);

end;

Следует также упомянуть о еще одной альтернативе передачи строк в DLL — типе

WideString

BSTR

WideString

AnsiString

WideString

SysAllocString

SysFreeString

ShareMem

Отметим одну ошибку, которую делают новички, прочитавшие комментарий про

ShareMem

PChar

function SomeFunction(...): PChar;

var

 S: string;

begin

 // Здесь присваивается значение S

 Result := PChar(S);

end;

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

S

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

Эта проблема связана с тем, что у человека есть определенные интуитивные представления о порядке выполнения действий программой, однако компилятор не всегда им соответствует. Рассмотрим следующий код (листинг 3.47, пример OpOrder на компакт-диске).

var

 X: Integer;

function GetValueAndModifyX: Integer;

begin

 X := 1;

 Result := 2;

end;

procedure TForm1.Button1Click(Sender: TObject);

var

 A1, A2: Integer;

begin

 X := 2;

 A1 := X + GetValueAndModifyX;

 X := 2;

 А2 := GetValueAndModifyX + X;

 Label1.Caption := IntToStr(A1);

 Label2.Caption := IntToStr(A2);

end;

Суть этого примера заключается в том, что функция

GetValueAndModifyX

X

GetValueAndModifyX

A1

X

GetValueAndModifyX

А2

A1

А2

and

or

xor

procedure TForm1.Button2Click(Sender: TObject);

var

 A1, A2: Extended;

begin

 X := 2;

 A1 := X / GetValueAndModifyX;

 X := 2;

 A2 := GetValueAndModifyX / X;

 Label1.Caption := FloatToStr(A1);

 Label2.Caption := FloatToStr(A2);

end;

В результате выполнения этого кода

A1

A2

X

Если бы функция

GetValueAndModifyX

Random

Примечание

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

Ради интереса посмотрим, что будет, если вторым аргументом тоже будет функция, зависящая от

X

function GetX: Integer;

begin

 Result := X;

end;

procedure TForm1.Button3Click(Sender: TObject);

var

 A1, A2: Integer;

begin

 X:= 2;

 A1 := GetX + GetValueAndModifyX;

 X := 2;

 A2 := GetValueAndModifyX + GetX;

 Label1.Caption := IntToStr(A1);

 Label2.Caption := IntToStr(A2);

end;

Здесь

A1

A2

procedure TForm1.Button1Click(Sender: TObject);

var

 A1, A2: Integer;

begin

 X := 2;

 A1 := X;

 Inc(A1, GetValueAndModifyX);

 X := 2;

 A2 := GetValueAndModifyX;

 Inc(A2, X);

 Label1.Caption := IntToStr(A1);

 Label2.Caption := IntToStr(A2);

end;

Такой код, несмотря на побочные эффекты функции

GetValueAndModifyX

Примечание

Другие компиляторы могут использовать иной порядок вычисления операндов. Так, FreePascal вычисляет их в том порядке, в каком они встречаются в выражении, т.е. в первом примере

А1

получит значение 4,

А2

— 3.

Для демонстрации этого "подводного камня" нам потребуется проект, на форме которого находится компонент

TUpDown

OnClick

procedure TForm1.UpDown1Click(Sender: TObject; Button: TUDBtnType);

begin

 Application.MessageBox('Text', 'Caption', MB_OK);

end;

Теперь, если запустить программу и нажать на верхнюю кнопку

UpDown1

TUpDown

Position

Min

Position

OnClick

Min

Position

OnClick

OnChanging

OnChangingEx

OnClick

OnClick

Если этот код пройти по шагам в отладчике, то никакого зацикливания не возникает:

OnClick

Причина этой проблемы в том, как VCL обрабатывает сообщения, которые система помещает в очередь. При нажатии на кнопку компонента

TUpDown

WM_LBUTTONDOWN

WM_NOTIFY

TUpDown

csCaptureMouse

WM_LBUTTONDOWN

Примечание

Монопольное использование мыши означает, что любые сообщения, связанные с мышью, будут поступать захватившему мышь окну даже если ее курсор в это время находится за пределами данного компонента. Примером захвата мыши может служить любая кнопка: щелкните мышью над любой кнопкой на экране и, не отпуская клавиши мыши, начните перемещать курсор. Когда курсор будет выходить за пределы кнопки, она будет отжиматься, находить на нее — снова нажиматься. Теперь отведите курсор за пределы кнопки, отпустите клавишу мыши и снова подведите его к кнопке. Кнопка не нажмется. Это происходит потому, что пока клавиша мыши удерживается нажатой, мышь захвачена кнопкой, и сообщение об отпускании клавиши мыши передаётся кнопке, независимо от того, над каким окном находится курсор. Это позволяет кнопке правильно реагировать на отпускание пользователем мыши, в том числе и за ее пределами.

Затем начинает обрабатываться событие

WM_NOTIFY

TUpDown

TUpDown.OnClick

WM_LBUTTONUP

TUpDown

WM_LBUTTONUP

UpDown1

WM_LBUTTONDOWN

WM_NOTIFY

В этой проблеме виновата VCL, которая зачем-то назначает компоненту

TUpDown

csCaptureMouse

UPDOWN_CLASS

TUpDown

csCaptureMouse

UpDown1.ControlStyle := UpDown1.ControlStyle - [csCaptureMouse];

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

OnCreate

Отметим, что в Windows предусмотрено специальное сообщение —

WM_CANCELMODE

UpDown1

TUpDown

WindowProc

Чтобы увидеть этот "подводный камень", создадим проект, содержащий две формы: главную

Form1

Form2

Form1

Form2

Во второй форме напишем обработчик события

OnClose

caFree

WndProc

type

 TForm2 = class(TForm)

  procedure FormClose(Sender: TObject; var Action: TCloseAction);

 private

  S: string;

 protected

  procedure WndProc(var Message: TMessage); override;

 public

  constructor Create(AOwner: TComponent); override;

 end;

.... 

constructor TForm2.Create(AOwner: TComponent);

begin

 S := 'abc';

 inherited;

end;

procedure TForm2.WndProc(var Message: TMessage);

begin

 inherited;

 S[2] := 'x'; { * }

end;

procedure TForm2.FormClose(Sender: TObject; var Action: TCloseAction);

begin

 Action := caFree;

end;

Обратите внимание, что в конструкторе сначала присваивается значение полю

S

S

nil

WndProc

S

nil

S

Запустим программу и попытаемся закрыть второе окно. Возникнет исключение Access Violation: Write of address 00000001. Проблема будет в строке, отмеченной

{*}

При

Action = caFree

TCustomForm.Release

Form2

Release

Release

При вызове

Release

CM_RELEASE

CM_RELEASE

CM_RELEASE

Система передает управление оконной процедуре. Для каждого экземпляра визуального компонента VCL создает свою оконную процедуру с помощью

MakeObjectInstance

MainWndProc

WindowProc

WndProc

WndProc

CM_RELEASE

Dispatch

Dispatch

message

TCustomForm

CMRelease

И здесь начинается самое интересное.

CMRealease

Free

Free

CMRealease

Dispatch

WndProc

MainWndProc

CM_RELEASE

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

Self

В данном примере получается следующее: сначала

CM_RELEASE

S

nil

S

nil

Обращение в аналогичной ситуации к нефинализируемым полям (целым, вещественным, логическим и т. п.) обычно не приводит к исключению. Это связано с тем, что менеджер памяти Delphi обычно не сразу отдаёт системе ту память, которую освобождает объект, поэтому программа, с точки зрения системы, имеет полное право ею пользоваться. Поля объекта не очищаются, и его образ продолжает храниться в памяти, просто менеджер памяти помечает эту область как неиспользуемую и может в любой момент выделить ее для хранения другого объекта. Это создает иллюзию того, что объект продолжает существовать и позволяет работать с уже несуществующим объектом. Но это все равно некорректно, потому что любое перераспределение памяти в данной ситуации может привести к непонятной ошибке.

Посмотрим. что будет, если строку

S[1] := 'x'

S := IntToStr(Msg.Msg)

S

nil

Отметим, что для вновь созданной строки память может быть выделена таким образом, что она наложится на те ячейки, в которых хранились значения полей уничтоженной формы, в том числе значение

S

Аналогичная проблема может появляться не только при перекрытии

WndProc

CMRelease

Совершенно непонятно, почему разработчики VCL реализовали такой заведомо некорректный механизм работы

Release

CM_RELEASE

Application

Application

Эта проблема обнаружена во всех версиях Delphi с 3-й по 2007-ю (в других версиях не проверялась). Самый простой способ ее преодоления — отмена опасных действий, если получено сообщение

CM_RELEASE

procedure TForm2.WndProc(var Message: TMessage);

begin

 inherited;

 if Msg.Msg <> CM_RELEASE then s[2] := 'x';

end;

Другой способ заключается в том. чтобы перенести обработку

CM_RELEASE

Application

OnMessage

TApplicationEvents

OnMessage

procedure TForm1.ApplicationEvents1Message(var Msg: tagMSG; var Handled: Boolean);

var

 I: Integer;

begin

 if Msg.Message = CM_RELEASE then

  for I := 0 to Screen.FormCount - 1 do

   if Screen. Forms[I].Handle = Msg.hwnd then

   begin

    Screen.Forms[I].Free;

    Handled := True;

    Exit;

   end;

end;

Событие

OnMessage

CM_RELEASE

Создадим новый проект в Delphi, поместим на форму кнопку и метку и создадим следующий обработчик нажатия кнопки (листинг 3.55, пример ClassName на компакт-диске).

procedure TForm1.Button1Click(Sender: TObject);

var

 CI: TWndClass;

 S: string;

 procedure DoGetClassInfo;

 begin

  GetClassInfo(hInstance, PChar('TForm' + IntToStr(1)), CI);

 end;

begin

 DoGetClassInfo;

 S := 'abcde' + IntToStr(2);

 Label1.Caption := CI.lpszClassName;

end;

Что будет выведено на экран в результате выполнения этого кода? Так как класс называется "TForm1", логично предположить, что именно это и будет выведено. На самом деле мы увидим abcde2 — ту строку, которая присвоена переменной

S

Разберемся, как значение переменной

S

CI.lpszClassName

lpszClassName

LPCTSTR(PChar)

GetClassInfo

Функция

GetClassInfo

lpszClassName

В приведенном примере в качестве аргумента

GetClassInfo

string

PChar

GetClassInfo

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

DoGetClassInfo

Освободившуюся память менеджер памяти не сразу возвращает системе придерживает, чтобы иметь возможность быстрее выделить память при следующем запросе. Таким образом, после завершения работы

DoGetClassInfo

CI.lpszClassName

Когда присваивается значение переменной

S

CI.lpszClassName

S

Примечание

В Delphi до 7-й версии включительно описанный эффект наблюдается при любой длине строки, присваиваемой переменной

S

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

S

, слишком сильно отличается по размеру от

'TForm1'

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

Если в данном примере не выносить вызов функции

GetClassInfo

DoGetClassInfo

Button1Click

Button1Click

S

S

Принципиально и то, что в обоих случаях (в функции

GetClassInfo

S

GetClassInfo

S

Избежать проблемы можно двумя способами. Во-первых, не следует передавать значение поля

lpszClassName

GetClassName

GetClassName

lpszClassName

Если в секции

published

Single

Double

EReadError

Double

Extended

X

-1e15 < х <= MinInt - 1

или

MaxInt + 1 <= X < 1e15

Не совсем понятно, при чем здесь значения

MaxInt

MinInt

Single

MaxInt

MinInt

Single

Ошибка обнаружена в Delphi 5 и 6, причем в Delphi 5 попытка ввести значение из указанного диапазона также может привести к ошибке и в режиме проектирования, при переключении между текстом модуля и формой. В Delphi 6 были замечены ошибки только при запуске программы, в режиме проектирования они не возникали. В Delphi 7 эта проблема уже решена, указанные значения свойств не приводят к ошибкам. В более ранних версиях Delphi проблема, естественно, также отсутствует, потому что в них dfm-файл всегда представляется в бинарной форме.

Для решения проблемы могут быть рекомендованы два способа.

1. Обновить Delphi до седьмой (или более поздней) версии.

2. Выбрать бинарную форму dfm-файла. Для этого нужно щёлкнуть правой кнопкой мыши на форме и в открывшемся меню убрать галочки с пункта Text DFM. 

Можно также отказаться от присвоения проблемных значений свойствам в режиме проектирования и присваивать их во время выполнения программы.

Windows позволяет с каждой строкой списка элементов управления

ListBoх

ComboBox

TObject

TComboBox.Items.Objects[Index]

TListBox.Items.Objects[Index]

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

ComboBox1.Items.Objects[I] := TObject(17);

I := Integer(ComboBox1.Items.Objects[I]);

Если таким образом связать со строкой значение -1, то при попытке получить его во всех версиях Delphi до 7-й включительно возникнет исключение

EStringListError

procedure TForm1.Button1Click(Sender: TObject);

var

 I: Integer;

begin

 ComboBox1.Items.Clear;

 ComboBox1.Items.AddObject('Text', TObject(-1));

 I := Integer(ComboBox1.Items.Objects[0]); { * }

 Label1.Caption := IntToStr(I);

end;

Исключение возникнет при попытке выполнить строку, отмеченную звездочкой, хотя очевидно, что индекс в данном случае корректен. Чтобы понять причину ошибки, необходимо рассмотреть, как осуществляется чтение значения, привязанного к строке, на уровне Windows API. Рассмотрим это на примере

TComboBox

ComboBox

CB_GETITEMDATA

CB_ERR

Метод

TComboBoxStrings.GetObject

Objects

CB_ERR

EStringListError

Проблема заключается в том, что константа

CB_ERR

CB_GETITEMDATA

TComboBoxStrings.GetObject

Аналогичная проблема по тем же причинам возникает и для

ListBox

LB_ERR

При использовании свойства

Objects

1. Пересмотреть алгоритм и отказаться от связывания значения -1 со строками.

2. Напрямую посылать

CB_GETITEMDATA

ComboBox

procedure TForm1.Button2Click(Sender: TObject);

var

 I: Integer;

begin

 ComboBox1.Items.Clear;

 ComboBox1.Items.AddObject('Text', TObject(-1));

 I := SendMessage(ComboBox1.Handle, CB_GETITEMDATA, 0, 0);

 Label1.Caption := IntToStr(I);

end;

Как уже было отмечено ранее, в BDS 2006 и более поздних версиях исключение не возникает. Это связано с новой реализацией метода

TCustomComboBoxStrings.GetObject

Items.Object

function TCustomComboBoxStrings.GetObject(Index: Integer): TObject;

begin

 Result := TObject(SendMessage(ComboBox.Handle, CB_GETITEMDATA, Index, 0));

 // Do additional checking on Count and Index here is so in the event

 // the object being retrieved is the integer -1 the call will succeed

 if (Longint(Result) = CB_ERR) and ((Count = 0) or

  (Index < 0) or (Index > Count)) then

  Error(SListIndexError, Index);

end;

Решение спорное, т.к. проверка корректности системой дополняется собственной проверкой индекса, и не совсем понятно, что делать в том случае, если система фиксирует какую-либо ошибку, не связанную с индексом. Но здесь Windows ставит разработчика в такие условия, что любое решение будет спорным, так что упреком по отношению к разработчикам VCL такая оценка их решения не является.

В таких элементах управления, как

TListView

TTreeView

TTreeNode.Data

TListItem.Data

TVM_GETITEM

LVM_GETITEM

Свойство

Anchors

Anchors

Программа WrongAnchors — это MDI-приложение, в котором открываются две дочерние формы разных классов:

ChildForm1

TChildForm1

ChildForm2

TChildForm2

Дочерняя MDI-форма приобретает отличный от заданного размер потому, что метод

CreateParams

Width

Height

CW_USERDEFAULT

CreateParams

TChildForm2

TChildForm1

procedure TChildForm2.CreateParams(var Params: TCreateParams);

begin

 inherited CreateParams(Params);

 Params.Width := Width;

 Params.Height : = Height;

end;

Значение

CW_USERDEFAULT

Position

poDefault

poDefaultSizeOnly

CreateParams

Position

Position

Anchors

Другой случай, когда окно может при создании иметь размеры, отличные от заданных при проектировании, — это когда свойство

WindowState

wsMaximized

Anchors

wsMaximized

WindowState

wsMaximized

WindowState

OnShow

Anchors

OnShow

Но самое интересное происходит, если свойство

WindowState

wsMaximized

Position

poDefault

poDefaultSizeOnly

Нельзя сказать, что разработчики Delphi не знакомы с этой проблемой, они даже что-то делают, чтобы ее решить. Начиная с BDS 2006 можно устанавливать значение свойства

WindowState

poDefault

poDefaultSizeOnly

Процедурные типы в Delphi делятся на обычные (унаследованные от Turbo Pascal) и указатели на методы. Первые — что указатели на простые процедуры и функции, вторые — на методы объектов. Чтобы вызвать метод объекта недостаточно знать, где его код располагается в памяти, нужно еще иметь ссылку на конкретный экземпляр класса, к которому относится данный метод (т.е. необходимо значение указателя

Self

SizeOf

Очевидно, что два указателя на метод равны тогда и только тогда, когда указывают на один и тот же метод одного и того же объекта, т.е. входящие в них указатели попарно равны. Однако компилятор сравнивает указатели на методы неправильно, и пример

MethodPtrCmp

TButton

procedure TForm1.ButtonlClick(Sender: TObject);

var

 P1, P2: procedure of object;

begin

 P1 := Button1.Update;

 P2 := Button2.Update;

 // Здесь компилятор сравнивает указатели на методы неверно,

 // давая ошибочный результат "равно"

 if @Р1 = @Р2 then Label1.Caption := 'Равно'

 else Label1.Caption := 'Не равно';

end;

Здесь мы получаем указатели на один и тот же метод разных объектов (для примера взяты класс

TButton

Update

Сравнить указатели на методы правильно можно с помощью типа

TMethod

SysUtils

TMethod = record

 Code, Data: Pointer;

end;

Так можно получать доступ к отдельным указателям, входящим в указатель на метод. Сравнение указателей на метод с помощью этого типа иллюстрирует листинг 3.61.

procedure TForm1.Button2Click(Sender: TObject);

var

 P1, P2: procedure of object;

begin

 P1 := Button1.Update;

 P2 := Button2.Update;

 // Правильный способ сравнения указателей на методы

 if (TMethod(P1).Data = TMethod(P2).Data) and

  (TMethod(P1).Code = TMethod(P2).Code) then

  Label1.Caption := 'Равно'

 else Label1.Caption := 'He равно';

end;

Здесь мы явным образом заставляем компилятор сравнивать оба указателя, поэтому получаем правильный результат Не равно.

Пусть у нас есть класс, описанный следующим образом (листинг 3.62).

TSomeClass = class private

 FProp1: Integer;

 function GetProp2: Integer;

public

 property Prop1: Integer read FProp1;

 property Prop2: Integer read GetProp2;

end;

В этом классе два свойства

Prop1

Prop2

FProp1

GetProp2

Пусть

X

TSomeClass

Prop1

@X.Prop1

FProp1

@X.Prop2

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

@

FProp1

К счастью, ситуации, в которых эта недоработка компилятора могла бы принести пользу, крайне редки. Но если вы все-таки столкнулись с такой ситуацией, настоятельно рекомендуем не поддаваться соблазну и искать другие способы решения проблемы. Если класс, к полю которого вы хотите получить доступ таким образом, написан вами, то это веский повод пересмотреть внешний интерфейс класса, т.к. при его проектировании скорее всего, были допущены серьезные ошибки. Если это «чужой» класс, подумайте о том, что в следующей версии этого класса автор может изменить реализация свойства, и тогда ваш код откажется компилироваться.

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

Проблему демонстрирует пример ParentWnd на компакт-диске. В нем создан компонент

TWrongCombo

TComboBox

type

 TWrongCombo = class(TComboBox)

 public

  destructor Destroy; override;

  procedure AddItem(const Title: string);

 end;

destructor TWrongCombo.Destroy;

var

 I: Integer;

begin

 for I := 0 to Items.Count - 1 do

  if Assigned(Items.Objects[I]) then

   Dispose(PDateTime(Items.Objects(I]));

 inherited;

end;

procedure TWrongCombo.AddItem(const Title: string);

var

 P: PDateTime;

begin

 New(P);

 P^ := Now;

 Items.AddObject(Title, TObject(P));

end;

Класс

TWrongCombo

AddItem

TDateTime

Items.Objects

TDateTime

TDateTime

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

Теперь попробуем воспользоваться компонентом. На главной форме программы

ParentWnd

TWrongCombo

procedure TForm1.BtnWrongComboClick(Sender: TObject);

begin

 if FWrongCombo = nil then

 begin

  FWrongCombo := TWrongCombo.Create(Self);

  FWrongCombo.Left := 10;

  FWrongCombo.Top := 10;

  FWrongCombo.Parent := Self;

  FWrongCombo.AddItem('One');

  FWrongCombo.AddItem('Two');

  FWrongCombo.AddItem('Three');

 end;

end;

Теперь, если нажать эту кнопку и затем попытаться закрыть форму, в деструкторе

TWrongCombo

EInvalidOperation

TWinControl.CreateWnd

Причина заключается в том, что к моменту вызова деструктора окно компонента уже удалено, свойство

Handle

Parent

nil

Items.Count

CB_GETCOUNT

SendMessage

Handle

CreateWnd

TWrongCombo

WS_CHILD

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

Поиск этого места оказывается не такой простой задачей, как хотелось бы, потому что разработчики VCL весьма странным образом реализовали удаление дочерних оконных компонентов в деструкторе класса

TWinControl

DestroyWindow

Положение спасает то, что об уведомлении окон заботится система Windows: всем окнам, которые удаляются в результате вызова функции

DestroyWindow

WM_DESTROY

Казалось бы, выход найден: нужно освобождать память в обработчике сообщения

WM_DESTROY

Parent

WM_DESTROY

TComboBox

TComboBox

WM_DESTROY

Items.Objects

Вообще говоря, механизм для этого предусмотрен в VCL — это флаг

csDestroying

ComponentState

TWinControl.Destroy

Destroying

WM_DESTROY

Destroying

WM_DESTROY

csDestroying

Тем не менее флаг

csDestroying

1. Удаляется непосредственно данный компонент.

2. Удаляется владелец компонента.

3. Удаляется родитель компонента.

В первом случае удаление начинается не с удаления окна, а с вызова деструктора компонента, и окно компонент удаляет уже сам, когда флаг csD

e

csDestroying

csDestroying

csDestroying

csDestroying

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

TRightCombo

TWrongCombo

WM_DESTROY

procedure TRightCombo.WMDestroy(var Msg: TMessage);

var

 I: integer;

 FinalDestruction: Boolean;

 P: TControl;

begin

 FinalDestruction := False;

 P := Self;

 while Assigned(P) do

 begin

  if csDestroying in F.ComponentState then

  begin

   FinalDestruction := True;

   Break;

  end;

  P := P.Parent;

 end;

 if FinalDestruction then

  for I := 0 to Items.Count - 1 do

   Dispose(PDateTime(Items.Objects[I]));

 inherited;

end;

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

Примечание

Есть еще одна очень распространенная причина получения ошибки "Control has no parent window" при разработке собственных компонентов — попытка обращения к свойствам, требующим наличия окна, до назначения свойства

Parent

. Например, такая ошибка появилась бы, если бы мы в наших наследниках

TComboBox

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

AddItem

. Свойство

Items.Objects

в случае

TComboBox

работает через оконные сообщения

CB_GETITEMDATA

и

CB_SETITEMDATA

, при попытке отправить которые будет использовано свойство

Handle

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

SetParent

после того, как отработает унаследованный

SetParent

. Необходимо только помнить, что

SetParent

может быть вызван не только при создании компонента и при необходимости позаботиться о том, чтобы инициализация выполнялась только при первом вызове

SetParent

с аргументом, отличным от

nil

.

Чтобы убедиться, насколько некорректно реализовано удаление компонентов в VCL, рассмотрим еще один пример (на компакт-диске он называется FrameDel). В этом примере на форму помещается фрейм с одним компонентом типа

TComboBox

type

 TFrame1 = class(TFrame)

  ComboBox1: TComboBox;

 private

  { Private declarations }

 public

  destructor Destroy; override;

  procedure AddComboItem;

 end;

destructor TFrame1.Destroy;

var

 I: Integer;

begin

 for I := 0 to ComboBox1.Items.Count - 1 do

  if Assigned(ComboBox1.Items.Objects[I]) then

   Dispose(PDateTime(ComboBox1.Items.Objects[I]));

 inherited;

end;

procedure TFrame1.AddComboItem;

var

 P: PDateTime;

begin

 New(P);

 P^:= Now;

 ComboBox1.Items.AddObject('Item ' + TimeToStr(P^), TObject(P));

end;

На форму в обработчике события

OnShow

AddComboItem

ComboBox1

ComboBox1.Items.Count

ComboBox1

ComboBox1.FHandle

ComboBox1.Items.Count

TComboBox1.Parent 

Parent

TCustomFrame.CreateParams

TComboBox1

Ранее мы говорили, что код компонента

TComboBox

ComboBox1

Items.Count

AddComboItem

Решением проблемы может стать уже опробованный способ: нужно обрабатывать сообщение

WM_DESTROY

Примечание

Если бы мы попытались использовать наследника от класса, например,

TPanel

вместо

TFrame

, ошибка при завершении работы программы возникла бы, компоненту

TPanel

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

ComboBox1

элементы до того, как будет назначено свойство

Parent

фрейма. Ошибки не возникнет, потому что окно фрейма будет создано успешно, а при последующем назначении свойства

Parent

фрейма в компоненте

ComboBox1

сработает механизм переноса элементов при создании нового окна, и пользователь увидит добавленные элементы.

Главным выводом этого раздела должно стать то, что последовательность удаления визуальных компонентов в VCL очень плохо продумана (видимо, это одно из самых неудачных мест в VCL), поэтому нужно соблюдать особую осторожность в тех случаях, когда освобождение ресурсов удаляемого оконного компонента может быть связано с обращением к его окну. Деструктор для этих целей, как мы убедились, не подходит, удаление следует выполнять в обработчике

WM_DESTROY