Нэш Трей - C# 2010. Ускоренный курс для профессионалов (2010) (1160865), страница 34
Текст из файла (страница 34)
Ясно, что при создании экземпляра объекта "за кулисами" выполняется большой объем работы по инициализации. А теперь рассмотрим причину, по которой инициализаторы полей производного класса вызываются перед вызовом конструктора базового класса через инициализатор в производном конструкторе. Причина довольно-таки тонкая. Внутри конструкторов в СЬН и в СЗ работают виртуальные методы, о которых пойдет речь в разделе "Наследование и виртуальные методы" далее в главе. На заметку! Если вы пришли из среды программирования Сч.+, то заметите, что такое поведение при вызове виртуальных методов в С» полностью отличается.
В Сьч на вызовы виртуальных методов в конструкторе полагаться нельзя, поскольку на момент выполнения тела конструктора таблица виртуальных методов (хтаЬ)е) еще не готова. Рассмотрим пример: пвьпч Яувсегю рпЬ11с с1авв А ) рпЬ11с ттгтпа1 чоьп Ооэоветп1пд)) ) Сопво1е.нгтгеьтпе) "А.розовеГП1пп))" ) Классы, структуры и объекты 125 роЬ11с й О ( Ооеоаесйаоч()т ) ) риЬ11с с1азз В: й ( роЬ11с очеггтые чо1с) ООБоаеСЬ1ОЧ() ( Сои зо1е .
Ыг1сеЬ гас ( "В. Ооеовегстсд () " Сопзо1е.ыгкяе)1ое( "х = (О)", х ) т ) роЬ11с В () :Ьззе () ( ) рг1чзге спг х = 123; ) роЬ11с с1азз Воггурогаг ( згас1с чотт( Ма с () ( в Ь = пеи В() и ) ) Ниже показан вывод этого кода: В.ОоЯоыегйапс() х = 123 Как видите, виртуальные вызовы работают прекрасно и при вызове в конструкторе класса й. Обратите внимание,что метод В.ООЯолтеСЬ1птт использует поле х. Если бы инициализаторы полей не запускались перед вызовом Ьазе, представьте себе неприятности, которые бы возникли при вызове виртуального метода в конструкторе класса й.
Именно поэтому инициализаторы полей запускаются перед вызовом базового конструктора, если конструктор содержит инициализатор. Инициализаторы полей также запускаются перед входом в тело конструктора, если в конструкторе не определен инициализатор. Уничтожение объектов Если создание объектов показалось сложным, приготовьтесь к еще худшему. Как известно, среда СЬК содержит в себе сборщик мусора, управляющий памятью от вашего имени. Можно создавать любое количество новых объектов и никогда не беспокоиться о явном освобождении занимаемой ими памяти. Подавляющее большинство ошибок в "родных" приложениях вызвано несоответствиями между выделением и освобождением памяти; эти ошибки имеют одно общее название — утечка памяти. Сборка мусора является техникой, предназначенной для исключения ошибок подобного рода, поскольку за отслеживание ссылок на объекты и уничтожение их экземпляров, когда они более не используются, теперь отвечает исполняющая среда.
Среда СЬК отслеживает каждую ссылку на управляемый объект в системе. Если во время сжатия кучи СЬК обнаруживает, что какой-то объект становится недоступным ни по одной ссылке, он помечается для удаления. При сжатии кучи сборщиком мусора все объекты.
помеченные для удаления, либо освобождают занятую ими память, либо 126 Глава 4 помещаются в очередь на удаление, если у них есть фнналнзатор. За это отвечает другой поток — поток финализатора, который проходит по очереди объектов и вызывает их финализаторы перед освобождением памяти. По завершении работы фннализатора память объекта освобождается при следующем проходе сборщика мусора, и объект окончательно уничтожается, уже безвозвратно. Финализаторы Писать финализаторы приходится редко, и на то есть немало причин.
При чрезмерном применении финализаторы могут снизить производительность СЬК, поскольку фннализируемые объекты существуют дольше, чем их нефинализируемые собратья. Даже размещение финализируемых объектов обходится дороже. Вдобавок финализаторы трудно писать из-за того, что нельзя делать какие-либо предположения о состоянии других объектов системы. Когда поток финализации проходит по объектам в очереди на финализацию.
он вызывает метод р1па11ге каждого из этих объектов. Метод р1па11ге представляет собой переопределение виртуального метода из Бузгек. ОЬ1есг; однако в С» не разрешается явно переопределять этот метод. Вместо этого должен быть написан деструктор, который выглядит как метод без типа возврата, без модификаторов. без параметров, идентификатором которого служит имя класса с предшествующим символом гильды (-). Деструкторы не могут вызываться явно в С(), они не наследуются, как не наследуются конструкторы.
Класс может иметь только один деструктор. Когда вызывается финализатор объекта, то вызывается каждый финализатор в цепочке наследования — от последнего к первому. Рассмотрим следующий пример: пв1по Бувгеап рпЬ11с с1авв Вазе ( -Вазе () ( Сопво1е.вг1сеь1пе( "Вазе.-Вазе()" )1 ) ) ро)о11с с1авв Оег1нег): Вазе ( -Оег1нео() ( Сопво1е.яг1се11пе( "Оег1чег(.-Оег1нег(()" )) ) рпп11с с1авв Впсгурогпс ( всаГ1с чо1г( Мауп() ( Оеггчел сег1неб = пее Оег1нег((); Как и можно было ожидать, ревультат выполнения кода будет таким: Оег1чег(.-Оеггчеб() Вазе.-Вазе() Хотя сборщик мусора теперь решает задачу по очистке памяти и вам не приходится об этом беспокоиться, когда заходит речь об уничтожении объектов, появляется масса новых забот.
Ранее уже упоминалось, что финализаторы выполняются в отдельном потоке СЬК. Поэтому код, который объекты выполняют внутри деструктора, должен быть Классы, структуры и объекты 127 безопасным в отношении потоков, к тому же в финализаторе никогда не следует использовать другие объекты, поскольку в этот момент они могут быть уже финализированы или уничтожены. Сюда относятся объекты, являющиеся полями класса, которому принадлежит финализатор. Нет никакого гарантированного способа узнать точно, когда будет вызван финализатор, или в каком порядке будут вызваны финзлизаторы двух зависимых или независимых объектов.
Это еще одна причина того. почему не следует вводить зависимости межтр объектами в блоке кода деструктора. После всего сказанного становится ясно, что в финализаторе не должно делаться ничего сложнее простой уборки, если она необходима. По сути, финализатор должен создаваться только тогда, когда объект имеет дело с неуправляемыми ресурсами некоторого рода. Однако если управление этими ресурсами производится через стандартный дескриптор тлт1п32, настоятельно рекомендуется испольэовать для управления ими тип Яа1еиапо1ег. Написание оболочки вроде Бэйеиапс11ег— задача непростая, главным образом из-за финализатора и всех тех вещей, вызов которых нужно гарантировать во всех (дэже в совершенно непредсказуемых) ситуациях, таких как отсутствие свободной памяти или возникновение неожиданных исключений.
И, наконец, любой объект, имеющий фннализатор, должен реализовать шаблон ОтзрозаЫе (Освобождаемый). о котором я расскажу далее в разделе "Одноразовые объекты". Детерминированное уничтожение До сих пор все, что было показано касательно уничтожения объектов в среде со сборщиком мусора СЬК, можно назвать недетермннированным уничтожением. Это значит, что предсказать время выполнения кода деструктора для объекта нельзя.
Если кто-то пришел из мира "родного" С++, он согласится с тем, что там все совершенно иначе. В С++ деструкторы объектов кучи вызываются, когда пользователь явно удаляет объект. В СЬВ этим занимается сборщик мусора, так что об удалении объектов беспокоиться не нужно. С другой стороны. для объекта С++, расположенного в стеке, деструктор вызывается, как только управление покидает область определения этого объекта. Это называется детерминированным уничтожением, и оно чрезвычайно удобно при управлении ресурсами. Рассмотрим случай с объектом.
хранящим системный дескриптор файла. Такой находящийся в стеке объект в С++ может использоваться для управления жизненным циклом дескриптора файла. Когда объект создается, его конструктор захватывает дескриптор файла, и как только объект выходит из своего контекста (области определения), вызывается деструктор, код которого закрывает дескриптор файла.
Это избавляет клиентский код объекта от необходимости явного управления ресурсом. Это также предотвращает утечку ресурсов, поскольку даже если будет сгенерировано исключение в блоке кода, использующем объект, С++ гарантирует вызов деструкторов всех находящихся в стеке объектов — независимо от того, каким именно образом произошел выход из блока. Такая идиома называется "захват ресурса является инициализацией" (Кезоигсе Асс(и!зтйоп 1з 1ШПа)тзайоп — КАП), и она исключительно удобна для управления ресурсами. Язык С1т практически полностью утратил агу возможность автоматической очистки.
Конечно, если есть объект. который удерживает файл открытым и закрывает его в деструкторе, то беспокоиться о том, закрыт файл или нет, не нужно, но определенно возникнет вопрос о том, когда он будет закрыт. Дело в том, что в точности не известно, когда файл будет закрыт, если соответствующий код находится в финализаторе, который вызывается во время недетермннированной финализации. По атой причине считается дурным тоном помещать в финалиэатор код управления ресурсами, подобный закрытию файловых дескрипторов. Что, если объект уже помечен для финализации, 128 Глава 4 но его финализатор еще не вызван, и вы пытаетесь создать новый экземпляр объекта, конструктор которого пытается открыть тот же самый ресурс? В случае ресурсов с монопольным доступом при создании нового экземпляра произойдет сбой в коде конструктора.
Понятно, что ситуация подобного рода крайне нежелательна и, определенно, этого не ожидает клиент объекта. Вернемся еще раз к ранее упоминаемой проблеме порядка финализации. Если объект содержит в себе другой финализируемьгй объект, и внешний объект помещен в очередь финализации, то внутренний объект также может быть помещен в нее. Однако поток финализации просто проходит по очереди и обрабатывает содержащиеся в нем объекты индивидуально. Его не волнует, какой объект для какого является внутренним. Поэтому ясно, что существует вероятность того, что при обращении в коде деструктора к полю со ссылкой на некоторый объект, этот объект окажется уже финализированным.
Обращение к такому полю приводит к неопределенному поведению. Это блестящий пример того, как сборщик мусора, исключая сложность одного рода, заменяет ее усложнением иного рода. В реальных проектах следует по возможности избегать применения финализаторов. Они не только добавляют сложности, но и препятствуют управлению памятью, поскольку вынуждают такие объекты существовать дольше, чем объекты без финализатора. Это связано с тем, что они помещаются в список финализации, за очистку которого отвечает совершенно отдельный поток. В разделе "Одноразовые объекты" и в главе 13 рассматривается интерфейс 101эрозаЪ1е, включенный в библиотеку классов платформы, который предлагает упрощенную форму детерминированного уничтожения. Обработка исключений Важно обратить внимание на поведение исключений внутри контекста финализатора. Если вы пришли из мира Сч и то знаете, что разрешать исключениям распространяться за пределы деструктора неправильно, поскольку в определенных ситуациях это может привести к прерыванию работы приложения.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
