Where did variable = null as “object destroying” come from?

后端 未结 14 1832
无人共我
无人共我 2021-02-18 15:51

Working on a number of legacy systems written in various versions of .NET, across many different companies, I keep finding examples of the following pattern:

pub         


        
相关标签:
14条回答
  • 2021-02-18 16:22

    It comes from C++ code especially smart pointers. In that case it's rougly equivalent to a .Dispose() in C#.

    It's not a good practice, at most a developer's instinct. There is no real value by assigning null in C#, except may be helping the GC to break a circular reference.

    0 讨论(0)
  • 2021-02-18 16:23

    May be the convention of assigning null originated from the fact that had foo been an instance variable instead of a local variable, you should remove the reference before GC can collect it. Someone slept during the first sentence and started nullifying all their variables; the crowd followed.

    0 讨论(0)
  • 2021-02-18 16:23

    Consider a slight modification:

    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);
    } 
    

    The author(s) may have wanted to ensure that the great Vavoom (*) did not get pointers to malformed objects if an exception was previously thrown and caught. Paranoia, resulting in defensive coding, is not necessarily a bad thing in this business.

    (*) If you know who he is, you know.

    0 讨论(0)
  • 2021-02-18 16:28

    It is possible that it came from VB which used a reference counting strategy for memory management and object lifetime. Setting a reference to Nothing (equivalent to null) would decrement the reference count. Once that count became zero then the object was destroyed synchronously. The count would be decremented automatically upon leaving the scope of a method so even in VB this technique was mostly useless, however there were special situations where you would want to greedily destroy an object as illustrated by the following code.

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

    In the above code the object referenced by big would have lingered until the end without the call to Set big = Nothing. That may be undesirable if the other stuff in the method was a time consuming operation or generated more memory pressure.

    0 讨论(0)
  • 2021-02-18 16:28

    VB developers had to dispose all of their objects, to try and mitigate the chance of a Memory leak. I can imagine this is where it has come from as VB devs migrated over to .NEt / c#

    0 讨论(0)
  • 2021-02-18 16:29

    It comes from C/C++ where explicitly made setting your pointers to null was the norm (to eliminate dangling pointers)

    After calling 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;
    }
    

    Classic VB developers also did the same thing when writing their COM components to prevent memory leaks.

    0 讨论(0)
提交回复
热议问题