Обработчик завершения

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

__try

{

}

_finally // обработчик завершения

{

}

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

В приведенном примере гарантируется, что блок __finaly будет выполнен независимо от того, как будет осуществлен выход из блока __try: по ошибке или с помощью операторов перехода return, goto. Даже если программист использует longjump – блок __finaly будет все равно выполнен.

Блок __finaly можно использовать для освобождения ресурсов, чтобы избежать из утечки.

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

Для уменьшения накладных расходов от преждевременного завершения существует ключевое слово _leave. Его можно использовать внутри блока __try. Когда компилятор встречает это слово – происходит выход из блока __try и выполнение блока __finaly. Т.е. его можно рассматривать как переход на закрывающуюся скобку блока __try.В выражении фильтра можно вызвать функцию GetExceptionInformation() или GetExceptionCode () . Первая из них возвращает указатель на структуру EXCEPTION_POINTERS, которая содержит детальную ин-формацию об исключении; вторая возвращает только кодовое значение для исключения.

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

1. Программа, как система взаимодействия объектов.

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

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

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

Как объекты будут знать о существовании друг друга?

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

1) Программе необходима интегрированная структура данных, которая объединяет все ее объекты, независимо от их класса, времени и места создания.

2) В проге необходимы универсальные средства взаимодействия объектов.

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