Интересы общего характера: Finalize() и Lazy<T>

@Bretbas · Регистрация: 05.08.2013

Студворк — интернет-сервис помощи студентам

Читаю Троелсена. Появились некоторые вопросы. Чтобы не создавать две темы, решил сделать одну и назвать ее более обобщенно. Итак:
1. Типы, которые имеют неуправляемые ресурсы. Троелсен предлагает наследоваться от IDisposable, чтобы была возможность у пользователя освобождать неуправляемые ресурсы вручную + сделать финализатор, где также происходит освобождение этих же ресурсов. Я так понял, что если я делаю класс финализируемым, то создается лишняя таблица в памяти для сборщика ресурсов, и соответственно происходят лишнии инструкции, если все таки уничтожать объект будет сборщик. Вопрос в том, зачем тогда делать финализатор, если можно обойтись IDisposable? Ну ответ очевиден - для того, чтобы если человек забыл освободить, то сборщик мусора все равно освободит. Но тогда человек получается идиот, если в документации по использованию данного класса будет черным по белому написано, что освобождать НУЖНО вручную.
2. Смотрю отложенную инициализацию с помощью системного класса Lazy<T>. Троелсен пишет: В частности, для получения фактических хранимых данных (в этом случае — объекта AllTracks, поддерживающего 10 000 объектов Song) мы должны использовать доступ*ное только для чтения свойство Value класса Lazy<T> ."
Вопрос следующий, как это свойство может быть только для чтения, если свойства только для чтения могут быть инициализированы только в конструкторе класса? Получается, если оно так и есть, то это уже нифига не отложенная инициализация, и инициализация объекта класса T будет происходить при конструировании класса Lazy<T>. Смотрел объявления в классе Lazy<T>. Value там не стоит только для чтения. Ошибка Троелсена? Или я что-то не догоняю?

Ежевичный · 11.09.2017, 20:32

Сообщение от Bretbas

Но тогда человек получается идиот, если в документации по использованию данного класса будет черным по белому написано, что освобождать НУЖНО вручную

А программист не идиот, если при удалении объекта сокета, сетевое соединение останется открытым и недоступным никому? Или писать безопасный код - это для слабаков?

Сообщение от Bretbas

Смотрел объявления в классе Lazy<T>. Value там не стоит только для чтения.

Да?

C#
1
public T Value { get; }

@Bretbas · 11.09.2017, 20:42 **[ТС]**

Ежевичный,

Сообщение от Ежевичный

Или писать безопасный код - это для слабаков?

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

Сообщение от Ежевичный

Смотрел объявления в классе Lazy<T>. Value там не стоит только для чтения.

а readonly тогда что?

@kolorotur · 11.09.2017, 20:52

Сообщение от Bretbas

Но тогда человек получается идиот, если в документации по использованию данного класса будет черным по белому написано, что освобождать НУЖНО вручную.

Это дешевая отмазка ленивых известно кого

Хороший код должен быть устойчивым к криворуким дегенератам.

Сообщение от Bretbas

Если на поддержку финализации приходится дополнительная таблица, лишнии инструкции и тд

Наличие финализатора прописано в информации о типе.
Лишние инструкции избегаются нормальной реализацией IDisposable.

@Bretbas · 11.09.2017, 21:12 **[ТС]**

kolorotur,

Сообщение от kolorotur

Лишние инструкции избегаются нормальной реализацией IDisposable.

Вот что говорит Троелсен:

При размещении объекта в управляемой куче исполняющая среда автоматически определяет, поддерживается ли в нем специальный метод Finalize(). Если да, тогда она помечает его как финализируемый и сохраняет указатель на него во внутренней очереди, называемой очередью финализации. Очередь финализации представляет со*бой поддерживаемую сборщиком мусора таблицу, указывающую на все объекты, кото*рые должны быть финализированы перед удалением из кучи.
Когда сборщик мусора определяет, что наступило время удалить объект из памяти, он проверяет каждую запись в очереди финализации и копирует объект из кучи в еще одну управляемую структуру, называемую таблицей объектов, доступных для финали*зации. Затем он создает отдельный поток для вызова метода Finalize() на каждом объекте из этой таблицы при следующей сборке мусора В результате получается, что для окончательной финализации объекта требуется как минимум две сборки мусора.
Из всего сказанного следует, что хотя финализация объекта действительно гаран*тирует для объекта возможность освобождения неуправляемых ресурсов, она все равно остается недетерминированной по своей природе, и по причине дополнительной неза*метной обработки протекает гораздо медленнее.

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

@OwenGlendower · 11.09.2017, 21:36

Сообщение от Bretbas

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

Ты путаешь свойство с полем. Поле с модификатором readonly может быть инициализировано при объявлении или в конструкторе. Свойство с доступом только для чтения вообще не обязано инициализироваться. Например:

C#
1
2
3
4
5
6
7
class NewYear
{
    public int DaysLeft
    {
        get { var d = DateTime.Now; return (new DateTime(d.Year+1, 1, 1) - d.Date).Days; }
    }
}

Что касается Lazy<T>.Value, то оно устроено по похожему принципу - http://referencesource.microso... 46b56b87ff

@Bretbas · 11.09.2017, 21:48 **[ТС]**

OwenGlendower,

Сообщение от OwenGlendower

Ты путаешь свойство с полем. Поле с модификатором readonly может быть инициализировано при объявлении или в конструкторе.

Да, я перепутал. Тогда становится понятна реализация Lazy<T>

Ежевичный · 11.09.2017, 21:50

Не по теме:

Сообщение от Bretbas

а readonly тогда что?

Мог бы и сам почитать разницу между readonly и свойствами...

@kolorotur · 11.09.2017, 22:09

Сообщение от Bretbas

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

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

@Bretbas · 12.09.2017, 08:08 **[ТС]**

kolorotur,

Сообщение от kolorotur

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

Да, это я уже знаю

Ладно, в принципе понял, и услышал то, что хотел знать. Спасибо

Ежевичный,

Сообщение от Ежевичный

А программист не идиот, если при удалении объекта сокета, сетевое соединение останется открытым и недоступным никому? Или писать безопасный код - это для слабаков?

Сообщение от Ежевичный

Мог бы и сам почитать разницу между readonly и свойствами...

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

Ежевичный · 12.09.2017, 09:48

Не по теме:

Сообщение от Bretbas

Мне без разницы

Мне тоже без разницы, что ты думаешь.

Новые блоги и статьи Все статьи Все блоги /
делаю науч статью по влиянию грибов на сукцессию anaschu 13.03.2026 прикрепляю статью	SDL3 для Desktop (MinGW): Создаём пустое окно с нуля для 2D-графики на SDL3, Си и C++ 8Observer8 10.03.2026 Содержание блога Финальные проекты на Си и на C++: hello-sdl3-c. zip hello-sdl3-cpp. zip Результат:	Установка CMake и MinGW 13.1 для сборки С и C++ приложений из консоли и из Qt Creator в EXE 8Observer8 10.03.2026 Содержание блога MinGW - это коллекция инструментов для сборки приложений в EXE. CMake - это система сборки приложений. Здесь описаны базовые шаги для старта программирования с помощью CMake и. . .	Как дизайн сайта влияет на конверсию: 7 решений, которые реально повышают заявки Neotwalker 08.03.2026 Многие до сих пор воспринимают дизайн сайта как “красивую оболочку”. На практике всё иначе: дизайн напрямую влияет на то, оставит человек заявку или уйдёт через несколько секунд. Даже если у вас. . .
Модульная разработка через nuget packages DevAlt 07.03.2026 Сложившийся в . Net-среде способ разработки чаще всего предполагает монорепозиторий в котором находятся все исходники. При создании нового решения, мы просто добавляем нужные проекты и имеем. . .	Модульный подход на примере F# DevAlt 06.03.2026 В блоге дяди Боба наткнулся на такое определение: В этой книге («Подход, основанный на вариантах использования») Ивар утверждает, что архитектура программного обеспечения — это структуры,. . .	Управление камерой с помощью скрипта OrbitControls.js на Three.js: Вращение, зум и панорамирование 8Observer8 05.03.2026 Содержание блога Финальная демка в браузере работает на Desktop и мобильных браузерах. Итоговый код: orbit-controls-threejs-js. zip. Сканируйте QR-код на мобильном. Вращайте камеру одним пальцем,. . .	SDL3 для Web (WebAssembly): Синхронизация спрайтов SDL3 и тел Box2D 8Observer8 04.03.2026 Содержание блога Финальная демка в браузере. Итоговый код: finish-sync-physics-sprites-sdl3-c. zip На первой гифке отладочные линии отключены, а на второй включены:. . .

@Bretbas Каждому свое 533 / 219 / 81 Регистрация: 05.08.2013 Сообщений: 1,614

	Интересы общего характера: Finalize() и Lazy<T> 11.09.2017, 20:23. Показов 1185. Ответов 10 Метки нет (Все метки) Читаю Троелсена. Появились некоторые вопросы. Чтобы не создавать две темы, решил сделать одну и назвать ее более обобщенно. Итак: 1. Типы, которые имеют неуправляемые ресурсы. Троелсен предлагает наследоваться от IDisposable, чтобы была возможность у пользователя освобождать неуправляемые ресурсы вручную + сделать финализатор, где также происходит освобождение этих же ресурсов. Я так понял, что если я делаю класс финализируемым, то создается лишняя таблица в памяти для сборщика ресурсов, и соответственно происходят лишнии инструкции, если все таки уничтожать объект будет сборщик. Вопрос в том, зачем тогда делать финализатор, если можно обойтись IDisposable? Ну ответ очевиден - для того, чтобы если человек забыл освободить, то сборщик мусора все равно освободит. Но тогда человек получается идиот, если в документации по использованию данного класса будет черным по белому написано, что освобождать НУЖНО вручную. 2. Смотрю отложенную инициализацию с помощью системного класса Lazy<T>. Троелсен пишет: В частности, для получения фактических хранимых данных (в этом случае — объекта AllTracks, поддерживающего 10 000 объектов Song) мы должны использовать доступное только для чтения* свойство Value класса Lazy<T> ." Вопрос следующий, как это свойство может быть только для чтения, если свойства только для чтения могут быть инициализированы только в конструкторе класса? Получается, если оно так и есть, то это уже нифига не отложенная инициализация, и инициализация объекта класса T будет происходить при конструировании класса Lazy<T>. Смотрел объявления в классе Lazy<T>. Value там не стоит только для чтения. Ошибка Троелсена? Или я что-то не догоняю? 0