Prev: ReDim'ed Array size
Next: Borderless Borderless Form
From: Ralph on 13 Oct 2009 11:19 "Bob Butler" <noway(a)nospam.ever> wrote in message news:uilnRvATKHA.4144(a)TK2MSFTNGP02.phx.gbl... > > "Ralph" <nt_consulting64(a)yahoo.com> wrote in message > news:OWom1qATKHA.504(a)TK2MSFTNGP06.phx.gbl... > > Bob Butler wrote: > >> "Ralph" <nt_consulting64(a)yahoo.com> wrote in message > >> news:eqPd7NATKHA.4020(a)TK2MSFTNGP05.phx.gbl... > >>> Simon Woods wrote: > >>>> On 13/10/2009 12:45, Ralph wrote: > >>>> > >>> > >>> For completeness (is that a word? <g>) since this is another area > >>> that can also be confusing ... VB performs reference counting on > >>> objects passed ByVal, but doesn't on object references passed ByRef. > >> > >> I think that's misleading; VB always does reference counting but when > >> passing 'ByRef' no additional reference is created so the count is not > >> incremented. Passing 'ByVal' does create an additional reference and > >> that does increment the count. > > > > I've heard it explained that way too, but felt that was equally > > "misleading". > > Using your sample code as a basis: > > DestroyJunkByValue cls > Debug.Print cls.Junk > > DestroyJunkByReference cls > Debug.Print cls.Junk ' errors > > Private Sub DestroyJunkByValue(ByVal cs As CJunk) > cs.Junk = 10 > Set cs = Nothing > End Sub > > Private Sub DestroyJunkByReference(ByRef cs As CJunk) > cs.Junk = 10 > Set cs = Nothing > End Sub > > If you took the subs and rewrote them in-line you'd have this: > > 'DestroyJunkByValue cls > set cs=cls ' passing ByVal causes VB to create the new ref > cs.junk=10 > set cs=nothing > Debug.Print cls.Junk > > 'DestroyJunkByReference cls > cls.junk=10 ' passing ByRef causes VB to use the same reference > set cls=nothing > Debug.Print cls.Junk ' errors > > In the ByRef case only the names are changed to confuse the innocent > No disagreement. -ralph
From: Scott M. on 14 Oct 2009 15:40
"Larry Serflaten" <serflaten(a)usinternet.com> wrote in message news:OTYzm8$SKHA.4692(a)TK2MSFTNGP06.phx.gbl... > > "Simon Woods" <simonjwoods(a)hotmail.com> wrote >> If I have a factory method like this in a module (or class) >> >> Public Function CreateMyObject() as MyObject >> >> dim myLocalObject as MyObject >> >> Set myLocalObject = new MyObject >> Set CreateMyObject = myLocalObject >> End Function >> >> and in another class I instantiate it >> >> Private Sub Test >> >> Dim myRemoteObject as MyObject >> >> Set myRemoteObject = Factory.CreateMyObject >> ... >> >> End Sub >> >> Will myLocalObject get destroyed when Sub Test finishes? > > > The two variables myLocalObject and myRemoteObject reference > the same object, as you may have surmised. When CreateMyObject > exits, myLocalObject falls out of scope, releasing its reference to the > created object. So to answer the question; Does myLocalObject > get destroyed when Sub Test finishes, that would be a no, correct? Well, I think you are referring to the underlying object that myLocalObject is pointing to, rather than the reference to the object (myLocalObject). The reference is destroyed after CreateMyObject completes, but the object persists until Test completes. > > When Sub Test 'finishes', myLocalObject is not referencing anything. Actually, as soon as CreateMyObject ends, myLocalObject (the reference) is gone completely, so it can't be set to a null reference. I > When Sub Test ends, the variable myRemoteObject is actually the > only (remaining) reference to the created object, and upon exit, it too > falls out of scope. It is at that time the created object gets destroyed. > (there was only one created object throughout....) Yep. |