Где сделал переменную = пустой указатель как, “уничтожение объекта” прибывает из?

Разработчики VB должны были избавиться от всех своих объектов, чтобы попытаться уменьшить вероятность утечки памяти. Я могу представить, откуда он появился, когда разработчики VB перешли на .NEt / c #

Возможно, соглашение о присвоении null возникло из-за того, что если бы foo был переменной экземпляра вместо локальной переменной, вам следует удалить ссылку, прежде чем сборщик мусора сможет ее собрать. . Кто-то заснул во время первого предложения и начал обнулять все их переменные; толпа последовала за ним.

Я много раз видел это в коде VBScript (классический ASP), и я думаю, что это исходит оттуда.

Это чаще встречается в языках с детерминированной сборкой мусора и без RAII, таких как старый Visual Basic, , но даже там это не нужно , и там часто приходилось ломать циклические ссылки. Так что, возможно, это действительно связано с плохими программистами на C ++, которые повсюду используют тупые указатели. В C ++ имеет смысл установить для немых указателей значение 0 после их удаления, чтобы предотвратить двойное удаление.

Это происходит из C / C ++, где выполнение free () / delete для уже выпущенного указателя могло привести к сбою, в то время как освобождение NULL-указателя просто ничего не дало.

Это означает, что эта конструкция (C ++) вызовет проблемы

void foo()
{
  myclass *mc = new myclass(); // lets assume you really need new here
  if (foo == bar)
  {
    delete mc;
  }
  delete mc;
}

, в то время как она будет работать

void foo()
{
  myclass *mc = new myclass(); // lets assume you really need new here
  if (foo == bar)
  {
    delete mc;
    mc = NULL;
  }
  delete mc;
}

Заключение: ИТ совершенно не нужны для C #, Java и почти любого другого языка сбора мусора.

Это происходит из C / C ++, где явная установка для ваших указателей значения NULL была нормой (чтобы исключить висячих указателей )

После вызова free ():

#include <stdlib.h>
{
    char *dp = malloc ( A_CONST );

    // Now that we're freeing dp, it is a dangling pointer because it's pointing
    // to freed memory
    free ( dp );

    // Set dp to NULL so it is no longer dangling
    dp = NULL;
}

Классические разработчики VB также поступали так же при написании своих COM-компонентов, чтобы предотвратить утечку памяти.

Возможно, он пришел из VB, который использовал стратегию подсчета ссылок для управления памятью и времени жизни объекта. Установка ссылки на Nothing (эквивалент null) уменьшит счетчик ссылок. Как только этот счетчик становится равным нулю, объект синхронно уничтожается. Счетчик будет автоматически уменьшаться при выходе из области действия метода, поэтому даже в VB этот метод был в основном бесполезен, однако были особые ситуации, когда вам нужно было жадно уничтожить объект, как показано в следующем коде.

Public Sub Main()
  Dim big As Variant
  Set big = GetReallyBigObject()
  Call big.DoSomething
  Set big = Nothing
  Call TimeConsumingOperation
  Call ConsumeMoreMemory
End Sub

В приведенном выше коде объект, на который ссылается big , задержался бы до конца без вызова Set big = Nothing . Это может быть нежелательно, если другие вещи в методе были трудоемкими операциями или создавали дополнительную нагрузку на память.

Я думаю, что раньше это было обычным недоразумением среди бывших разработчиков C / C ++. Они знали, что сборщик мусора освободит их память, но не понимали, когда и как. Просто очистите его и продолжайте :)

Я подозреваю, что этот паттерн возникает из-за перевода кода C++ на C# без паузы, чтобы понять различия между финализацией C# и финализацией C++. В C++ я часто обнуляю вещи в деструкторе, либо в целях отладки (чтобы вы могли увидеть в отладчике, что ссылка больше не действительна), либо, редко, потому что я хочу, чтобы умный объект был освобожден. (Если смысл в этом, я лучше вызову Release на нем и сделаю смысл кода кристально ясным для сопровождающих). Как вы заметили, в C# это практически бессмысленно.

В VB/VBScript вы тоже постоянно видите этот паттерн, по разным причинам. Я немного размышлял о том, что может быть причиной этого здесь:

http://blogs.msdn.com/b/ericlippert/archive/2004/04/28/122259.aspx

Рассмотрим небольшая модификация:

public void FooBar() 
{ 
    object foo = null; 
    object bar = null; 

    try 
    { 
       foo = new object(); 
       bar = new object(); 

       // Code which throws exception. 
    } 
    finally 
    { 
       // Destroying objects 
       foo = null; 
       bar = null; 
    } 
    vavoom(foo,bar);
} 

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

(*) Если вы знаете, кто он, вы знаете.

Это происходит из кода C ++, особенно интеллектуальных указателей . В этом случае это примерно эквивалентно .Dispose () в C #.

Это плохая практика, в лучшем случае инстинкт разработчика. Нет никакого реального значения путем присвоения null в C #, за исключением того, что это может помочь GC разорвать циклическую ссылку.

Я вижу, что это происходит либо из-за неправильного понимания того, как работает сборка мусора, либо из-за попытки заставить сборщик мусора немедленно сработать - возможно, из-за объектов foo и bar довольно большие.

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

Вероятно, он возник не из Java, поскольку использование его для чего-либо, кроме статической переменной, также не имеет смысла в Java.