Ну а если такая ситуация, что объекты используются часто, и где-то вызвался Dispose. Если сборщик сразу не освобождает память, то может быть попытка использования объекта, для которого уже вызван Dispose. К чему это может привести? Вот эта неопределённость мне и не нравится. В С++ ты сделал delete объекта по указателю, присвоил указателю null и всё это произошло сразу - нет никаких недомолвок, что де сборщик какой-то не сразу всё удалил или удалил лишь частично.
Меня просто нервирует это. Сначала декларируется, что не надо думать об освобождении памяти. Потом вводится понятие Dispose (и это без всяких unsafe - с unsafe всё ещё усложняется). А потом говорится, что даже после всех этих Dispose и ручного вызова GC.Collect
не обязательно сразу ресурсы будут освобождены. Сборщик мусора ещё подумает. Вводится понятие поколений объектов в мусорной куче (хорошее название для "кучи", хе-хе). Потом говорится, что и правилу поколений сборщик не всегда следует - есть де случаи, когда и объекты, которые уже должны быть удалены, всё ещё живут. И вот при такой неопределённости предлагается писать приложения.
При такой неопределённости простое присвоение null выглядит простым и эффективным способом избавиться от этих костылей. У нас же уже есть шаблон if (obj != null). Для таких общепринятых проверок простое присвоение null может быть хорошей практикой и гарантией, что не будет использования объекта, для которого уже был вызван Dispose, но который ещё фактически не освободился. Или освободился не полностью.
Я думаю, тут загвоздка вот в чём.
Нужно разделять управление памятью (предотващение утечек и пр.) и логику использования объектов в коде.
GC занимается управлением памятью - т. е. предотвращает утечки и снимает с программиста работу по ручному освобождению ресурсов. Но он не защищает от использования объектов, которые по логике уже освобождены, а по факту - нет. От этого защищает присвоение null.
Когда говорят, что присваивать null не нужно, имеют ввиду, что
это не нужно делать для освобождения ресурсов . Но не для защиты от использования объектов, которые по логике (только по логике, но ещё не на самом деле) уже освобождены. Сборщик мусора может сработать сильно позже и "занулить", объект, а использование объекта может быть раньше этого "зануления". Поэтому, чтобы такого неправильного использования не произошло, надо присваивать null объекту, который больше не предпоплагается использовать.
Это не освобождает ресурсы, а всего лишь сигнализирует программисту о том, что этот объект СЧИТАЕТСЯ ОСВОБОЖДЁННЫМ.
Как вы считаете?
Просто уже нервирует, когда видишь проект, в котором в порядке вещей куча подобных вот
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
public void Shutdown()
{
if (RasterState != null)
{
RasterState.Dispose();
RasterState = null;
}
if (DepthStencilView != null)
{
DepthStencilView.Dispose();
DepthStencilView = null;
}
if (DepthStencilState != null)
{
DepthStencilState.Dispose();
DepthStencilState = null;
}
if (DepthStencilBuffer != null)
{
DepthStencilBuffer.Dispose();
DepthStencilBuffer = null;
}
if (RenderTargetView != null)
{
RenderTargetView.Dispose();
RenderTargetView = null;
}
if (Device != null)
{
Device.Dispose();
Device = null;
}
if (SwapChain != null)
{
SwapChain.Dispose();
SwapChain = null;
}
}
