Check Before setting object = Nothing 1

[codemama]

I know there was some debate on whether you should set it to nothing or let VB take care of it.. However it is part of our company coding standards to set the object to nothing when done.

1. Do I need to check if the object exists before setting to Nothing? (more obvious in class vars).
If NOT obj Is Nothing Then Set obj = Nothing

2. Usually we dont create a new object just set it as that type or It is passed in by ref. (Private m_oTempCalls As MSXML2.DOMDocument30)
Do I still need to set to Nothing or check if not Nothing already.

Should I just make sure that any class level object gets set to nothing in the Class_terminate methods?


This is a COM++ app with VB 6 and VS C++

Thanks in advance.
New to the COM stuff..

 

[strongm]

>Can you elaborate a bit?

Because what we tend to call objects in VB are really references to objects. Most of the time all we really do in VB is increment and decrement the number of references to an object. Setting an object to Nothing merely decrements the objects reference counter. If and only if the reference counter reaches zero does the object destroy itself (and the articles dilettante references much earlier in the thread indicate some of the additional reference counter rules VB adheres to behind the scenes)

 

[BobRodes]

Ok, I understand what you're saying now. I guess my point is this: if you set a COM object reference to Nothing, the Release method of the iUnknown interface is called. If an object reference goes out of scope, the same Release method is called. As you mention, the Release method decrements a reference counter, and also calls a destructor on the object when the reference counter reaches 0.

So, I guess my point is a little higher level. From the standpoint of architectural standards, it strikes me that allowing an object to get destroyed when it runs out of scope is a stronger defensive programming technique than requiring that the object be reflexively set to nothing; for it automates a process that is otherwise manual. As far as I'm concerned, setting an object reference to nothing because it "might" otherwise stay open and also be the only reference the object has (which would indeed cause a memory leak, if one could stumble on a way to do that) is a wasteful and error-prone process--error-prone in the sense that someone, somewhere might forget to do it. It seems to me that it would be more productive to invest one's efforts in scope minimization, thereby leveraging the automated process already in place.

Bob

 

[dilettante]

It seems to me that it would be more productive to invest one's efforts in scope minimization, thereby leveraging the automated process already in place.

But this is just good practice in general.

I wonder of what got this started was those cases in which objects are not destroyed even when the reference count goes to zero?

My guess is that the whole process is opaque to most people, somebody got burned because they didn't call Quit on an instance of Excel or something, and they came up with the "set everything to nothing" mantra in a misguided attempt to keep further elephants away.

And as I mentioned there are cases like pooled object scenarios where you want to release your (proxy) reference as soon as possible so the object behind it can be reused. There you want to instantiate late and release early or you defeat the efficiencies of pooling. This was something Microsoft tried to encourage in ASP pages for example.

 

[BobRodes]

<But this is just good practice in general.
Of which I'm a fan.

<those cases in which objects are not destroyed even when the reference count goes to zero?
Yup. And where are they?

<My guess is...
I'd say that's a very accurate guess. Of course, this was also touted in all kinds of books for some time, as "serious" programmers, began writing books to show the "right" way to use VB as a "serious" programming language.

Given Microsoft's track record, it might have made more sense in earlier versions of VB.

 

[harebrain]

>ASP pages

A cloud of confusion between ASP/VBScript and VB6 is my guess as to what's at the root of this.

 

[dilettante]

Yup. And where are they?

See the Component Shutdown links I posted back on Nov. 13th or so in this thread.