Initialization

A.Create(8);

end.

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

Вызов деструктора несколько более проблематичен. Проблема заключается в том, что при вызове деструктора ему в регистре DL передается дополнительный флаг, который указывает на то, нужно ли освобождать занятую память (DL=1) или нет(DL=0). Средствами только языкаObject Pascal добиться вызова деструктора с передачей нуля невозможно. Поэтому единственным выходом является использование встроенного ассемблера.

При реализации не потребовалось явно вызывать деструктор, но если бы это было необходимо, то можно применить, например такой вариант. У общего предка TObject всех классов в языкеObject Pascal¹²определяется виртуальный конструкторDestroy и методFree, который вызывает деструктор, если ссылка на объект не имеет значениеnil. Аналогично этому можно объявить функциюStaticFree, которая будет вызывать деструктор, не освобождая при этом занятую память.

type

ClassI = class

...

procedure StaticFree;

end;

...

procedure ClassI.StaticFree;

const

vtDestroy = -4;

asm

mov dl,0 { установить флаг }

mov ecx,[eax] { получить адрес VMT }

call dword ptr [ecx].vtDestroy { вызвать деструктор }

end;

Функция использует следующие соглашения о вызове методов. По умолчанию используется модель вызова register, в соответствии с которой первый параметр - указатель на экземпляр класса передается через регистрEAX¹³. А указатель на виртуальный деструкторDestroy находится но смещению -4 вVMT.Тогда код инициализации и завершения будет выглядеть следующим образом:

Initialization

A.Create(8);

finalization

A.StaticFree;

end.

Недостатки данного подхода.

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

6. Технология написания и отладки приложений, работающих с распределенными объектами.

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

6.1. Этапы разработки программы.

Цикл разработки любого программного продукта, как правило, включает в себя следующие этапы (с различными вариациями):

1. Постановка задачи в словесной форме (техническое задание).

2. Построение математической модели.

3. Проектирование программного продукта и разработка алгоритмов.

4. Кодирование алгоритмов на языке программирования.

5. Автономная и комплексная отладка.

6. Изготовление документации, описаний и передача в эксплуатацию.

При использовании распределенных объектов этапы 1-3 и 6 мало отличаются от стандартных. Например, разработку программы можно вести как методом сверху вниз, так и методом снизу вверх. Но на этапах 4 и 5 возникают дополнительные трудности, которые не решаются стандартными методами.

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

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

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