set objects to Nothing on error / at end of function?
Terry McKiernan
to Nothing explicitly at the end of their scope, i.e. either when exiting a
function, terminating a class instance or shutting down a program? I have
heard it both ways directly from MS Tech Support and in articles in
magazines like VBPJ.
Specifically what I mean is, suppose I have a function (or class etc.) which
creates some local objects:
Dim objFoo As TypeLib.ClassName1 ' or As Object
Dim objBar As TypeLib.ClassName2 ' or As Object
Set objFoo = New TypeLib.ClassName1 ' or CreateObject("...
Set objBar = New TypeLib.ClassName2
... some code that uses these objects ...
At the end of the function, and/or in an error handler, should I kill them
off?
Set objFoo = Nothing
Set objBar = Nothing
Exit Function
Or should I just leave them alone, and trust VB to get rid of them for me?
Some authors religiously use Set X = Nothing to explicitly deallocate all
objects when they are done with them, while others say "the runtime engine
garbage collection handles this for you automatically, don't worry about
it". I even heard from MS Tech Support that you should NOT explicitly
deallocate objects, that sometimes it does not work properly and can leave
orphaned objects in memory, making a process not terminate. But, maybe this
was a bug in some old versions of VB and is no longer the case. No one
really seems to know.
Now, I realize of course that objects take up resources, so if I am done
with one I could release it right away to get the memory back. But let's
assume these are short, fast functions and the objects created have low
overhead. What I'm wondering about here is the general practice: deallocate
explicitly or not? It is necessary and/or worth your time to nuke the
objects by hand, and thus maintain that code each time you change the
function to use a new object, or should we just not worry about it?
What I've seen of .NET seems to indicate that all MS languages are getting
garbage collection as part of the common runtime. This makes me guess that
we should not bother with explicitly calling Set X = Nothing, and just let
the runtime handle things.
Any opinions? Any documented problems with doing it one way or the other?
Thanks everyone
Terry McKiernan
CoStar Group
Sjoerd Verweij
>to Nothing explicitly at the end of their scope, i.e. either when exiting a
>function, terminating a class instance or shutting down a program?
In VB6, generally, this is a good idea but superfluous when the scope
will do it for you.
>Some authors religiously use Set X = Nothing to explicitly deallocate all
>objects when they are done with them, while others say "the runtime engine
>garbage collection handles this for you automatically, don't worry about
>it".
VB6 does not have garbage collection in the way that that term is
commonly used in the .NET world, so it is a bit dangerous to call it
that. Just make sure you always say "VB6 garbage collection".
> I even heard from MS Tech Support that you should NOT explicitly
>deallocate objects, that sometimes it does not work properly and can leave
>orphaned objects in memory, making a process not terminate.
This can happen quite easily.
Sub A
Set Foo = New Bar
Set Yadda.MyFoo = Foo
Set Foo = Nothing ' *1
End Sub
In VB6, an object is cleaned up directly when nobody references it
anymore. Line *1 does not release the object, because Yadda is still
pointing to it. Some people advise against explicit Set X = Nothing
because a lot of programmers will see that line and assume that no
matter what, X will be cleaned up.
This is simply not necessarily the case, is causing a million errors
as we speak and is one of my big arguments for .NET.
Let's not even dive into the realm of circular references.
> What I'm wondering about here is the general practice: deallocate
> explicitly or not?
In VB6, IMHO: when it is efficient (however, noone seems to be able to
agree, as you have found out). In VB.NET: you don't because you can't.
You can set to nothing, which might clear the last reference, but that
does not mean that the object is actually destroyed. This is the
wonderful DF/Dispose discussion that has been raging on this server
for ages.
>What I've seen of .NET seems to indicate that all MS languages are getting
>garbage collection as part of the common runtime. This makes me guess that
>we should not bother with explicitly calling Set X = Nothing, and just let
>the runtime handle things.
Bother all you want; it's just not going to do you any good in .NET.
>Any opinions? Any documented problems with doing it one way or the other?
In VB6, it's usually superfluous because the object will be cleaned up
by going out of scope; in VB.NET, it's superfluous because you have no
say over when the GC will actually get rid of it.
Cormac J Gebruers
I advocate ALWAYS explicitly setting object variables to nothing regardless
of language, garbage collection or other issues. While in functions this may
seem trivial it does mean engineers code is consistent - when you're
finished with an object variable dump it in a way that everyone knows what
you're doing...with module level variables etc. this can assist
understanding a lot.
My logic is simple: It serves as a way of clearly identifying to subsequent
readers of the code what was intended. For the sake of a few extra lines it
can provide clarity. I don't like assumptions in code regardless of how
obvious they might be (arising largely from years of having to re-visit code
written by others several years later when the assumptions are no longer
obvious at all!)
Whether explicitly using the "set objFoo = nothing" statement carries a
performance overhead is an interesting question though - any answers?
Cormac [Gebruers]
NECL
Cork, Ireland.
"Terry McKiernan" <tmcki...@costargroup.com> wrote in message
news:uFo8eGPdAHA.2060@tkmsftngp05...
Matthew Curland
objects
> to Nothing explicitly at the end of their scope, i.e. either when exiting
a
> function, terminating a class instance or shutting down a program?
will automatically set all object variables to Nothing when they go out of
scope. For local variables, this happens when the procedure ends. For
module-level variables in class modules (including forms, controls, etc),
when the final release happens on the class (and after Class_Terminate is
run). For modules, when the program terminates. Setting them to Nothing
yourself is a waste of code: VB has to check if they are Nothing anyway and
always generates the code the code to release them, so you're just
duplicating existing code.
I've also noticed that many people who are religious about the Set = Nothing
do not take the same approach to strings and array types. They seem to be
perfectly happy with letting VB clean these types, but still religiously
maintain that it can't handle object types. You'll also see code that
contains a jump out of a With block (ie, without executing End With), but
still sets all locals to Nothing. The inconsistency here is that a With
block actually generates a hidden local object variable, but you don't have
access to it to explicitly set it to Nothing. VB treats hidden and visible
locals exactly the same when a procedure terminates. Since you are forced to
implicitly trust it with the hidden variables, you should also trust it with
the ones you define.
Let me preempt one comment from the opposing camp. A common argument for the
explicit 'Set = Nothing' approach is that this documents the intent of the
code, and even makes it easier to port the code to other languages. I don't
buy into this. Since the explicit code does not change the behavior of your
app in any significant way, it is essentially untestable, so any port
relying on it is relying on untested code. Also, unneeded teardown code
obscures necessary teardown code buy burying it in a bunch of noise, which
makes it harder to maintain the real teardown code.
There are times when you need to do an explict 'Set = Nothing', but none of
these have anything to do with protecting variables as they go out of scope.
The reasons I can think of are:
1) Breaking circular references. This is generally done in response to an
event or explicit method call. For example, if a form is circular with a
class instance, then Form_Unload is a good place to break the cycle.
2) A requirement for explicit teardown order. This is rare, but it does
happen. For example, if you apply two UnknownHook objects from my book to
the same object, then you need to remove the hooks (ie, set the objects to
nothing) in reverse order. If you follow the rule to not use explicit
teardown for non-order dependent code, then when you do see a 'Set =
Nothing', you know that the execution order is important.
3) Poorly designed object models. A robust object model allows its objects
to be released in any order and at any time, but you will occasionally meet
one that isn't robust. You should never extrapolate teardown rules for an
explicit object model into general rules for all VB code. A requirement for
explicit teardown should always be considered an exception, not a rule.
> What I've seen of .NET seems to indicate that all MS languages are getting
> garbage collection as part of the common runtime. This makes me guess
that
> we should not bother with explicitly calling Set X = Nothing, and just let
> the runtime handle things.
The VB6 runtime handles this now, but it doesn't use garbage collection. In
fact, the VB6 approach is diametrically opposed to the GC philosophy. VB6
has a strictly enforced no littering law, while GC actually forces you to
litter. In fact, in a GC system, the 'Set = Nothing' is even more useless
because any Finalize code does not run immediately as it does with the final
release in a COM-based system. While object systems with teardown order
dependencies were frowned upon in COM, they are considered downright evil in
GC land. -Matt
Matthew Curland
> performance overhead is an interesting question though - any answers?
twice, and the Set = Nothing code is more expensive than what VB does at the
end. Use debug symbols to look at the generated code and you'll see the cost
(Set = Nothing generates a vbaCastObj call, while implicit teardown
generates a series of optimized vbaFreeObj calls). Also, remember that code
size has performance implications as well. The bigger the program, the
longer it takes to load and run.
I would also have to disagree with you that Set = Nothing adds clarity. I
try to only write code that makes the program deviate from the implicit
behavior. By adding extra code that is trying to mimic the implicit
behavior, you make it harder to figure out which lines of code actually make
the program run differently. You would never subclass a window without
actually interacting with specific messages because a window procedure with
nothing more than a CallWindowProc forwarding call adds runtime overhead and
maintainability costs, but doesn't change the behavior of the program. Why
would you ever routinely follow a coding standard that bloats your program
but has no impact on the behavior of the program? Code that does nothing can
never be considered consistent because it is unverifiable. -Matt
Jonathan Allen
to nothing, this actually affects the object and is needed to free up the
resources it uses.
***************
> Set objFoo = Nothing
> Set objBar = Nothing
>
> Exit Function
This offers no performance advantage and thus wastes lines. And as you know,
every additional line is another chance for an error that isn't caught. For
instance, a code reviewer seeing that line may assume that you already
called dispose without checking for it.
In addition, setting a structure to Nothing resets all it's fields to their
default value. So there is a performance issue with value types.
If you can safely set an object to nothing early in the function (because
it's no longer needed, etc.), then do so too free up the resources it's
using. But if you have to wait till the very end, don't bother.
--
Jonathan Allen
This industry is always changing and whining won't stop it,
so either bail out now or enjoy the ride.
"Terry McKiernan" <tmcki...@costargroup.com> wrote in message
news:uFo8eGPdAHA.2060@tkmsftngp05...
Calvin Crumrine
Matthew Curland wrote:
I can't even begin to count the number of times I and other programmers have
gotten into trouble by relying on default/implicit behavior. I'll agree that
explicitly setting defaults can degrade performance (haven't noticed it myself
but I haven't been trying to get the nnnth degree of performance out of my apps
either-fast enough is fast enough even when it isn't as fast as possible) and
I'll even agree that you can't explicitly specify everything, nor does
explicitly specifying things guarantee that you won't have problems (as Sjoerd
said, explicitly setting an object = Nothing doesn't mean it will be destroyed)
but I think it's best to avoid/eliminate any problems you can so I'd say yes,
you should explictly set objects = Nothing when you're finished with them. JMO.
emu...@my-deja.com
I'm one of those programmers who explicitly sets all objects to
Nothing. I think I might be willing to switch religions, but there are
a couple things I don't understand. I've always heard that there were
certain situations were VB would fail to clean up properly. Now, I
always explicitly set my objects to Nothing so I haven't had this
problem but I have heard of other people who have. In fact, just a few
weeks ago, one of the other programmers I work with was having trouble
with his program. (In a nutshell, his program consists of one main EXE
and one ActiveX EXE.) Users were reporting that in certain unknown
situations, the ActiveX EXE remained in memory after it should have
been closed. He couldn't quite figure out why it happened sometimes and
sometimes it didn't. I told him that he should explicitly set all his
objects (forms, classes, database connections, etc.) to Nothing. Since
he has done that, the users haven't had this problem reoccur. Can you
reconcile this with your advice to not set objects to Nothing? Also,
you listed 3 situations where setting objects to Nothing are required.
Are there any other situations, such as buggy third-party components
that might require you explicitly set them to Nothing? Is it possible
that VB itself contains one or more bugs that prevent it from cleaning
up objects properly in certain situations?
Your help is greatly appreciated.
- Jim
In article <ek3bQmPdAHA.1808@tkmsftngp03>,
Sent via Deja.com
http://www.deja.com/
Sjoerd Verweij
>Nothing. I think I might be willing to switch religions, but there are
>a couple things I don't understand. I've always heard that there were
>certain situations were VB would fail to clean up properly.
Yep. It's called circular referencing. One app I had to work on had
stuff like this going on:
Proj1 (DLL)
Root1 = Class1
Class1
Collection Of Class2
Class2
mX = Root1
mY = Class1
Collection Of Class3
Class3
mX = Root1
mY = Class1
mZ = Class2
Proj2 (DLL)
RootA = ClassA
ClassA
mX = Class3
mY = Root1
mZ = RootA
Proj3 (EXE)
mX = Class1
mY = ClassA
mZ = Root1
>Users were reporting that in certain unknown
>situations, the ActiveX EXE remained in memory after it should have
>been closed.
Probably had something going on just like the situation described
above.
> I told him that he should explicitly set all his
>objects (forms, classes, database connections, etc.) to Nothing. Since
>he has done that, the users haven't had this problem reoccur. Can you
>reconcile this with your advice to not set objects to Nothing?
Then he was lucky. Can you describe, in the example above (and trust
me, it's immensely simplified -- the number of levels was actually 12
for Proj1 and 8 for Proj2) exactly in what order everything will be
destroyed, and whether or not Set X = Nothing would fix everything?
It doesn't.
>Is it possible
>that VB itself contains one or more bugs that prevent it from cleaning
>up objects properly in certain situations?
If you consider error-prone architecture a bug, yes.
Jonathan Allen
have
> gotten into trouble by relying on default/implicit behavior.
Just for giggles, describe a few.
--
Jonathan Allen
This industry is always changing and whining won't stop it,
so either bail out now or enjoy the ride.
"Calvin Crumrine" <Calvin_...@dced.state.ak.us> wrote in message
news:3A52551E...@dced.state.ak.us...
emu...@my-deja.com
> Yep. It's called circular referencing.
Yes, circular referencing has been discussed
- Jim
Steffen Ramlow
"Matthew Curland" <mat...@microsoft.com> wrote in message
news:ek3bQmPdAHA.1808@tkmsftngp03...
> > Is there a definitive answer as to whether or not you should set all
> objects
> > to Nothing explicitly at the end of their scope, i.e. either when
exiting
> a
> > function, terminating a class instance or shutting down a program?
> The definitive answer, which I'm sure some will disagree with, is NO.
yeah, beat those religious programmers matt! :-)
no, really guys. let VB (6?) do the job - it works!
Sjoerd Verweij
The times I've heard "so I set it to nothing, so it's cleaned up..."
or "so I concat all these fields, and it worked in 6.5, and now in 7.0
it's null, 7.0 sucks"...
Steven A. Mitchell
Matt gave all the good technical answers. Let me just add that there is
really no way to *prove* that VB always releases--because you cannot prove a
negative. However, I've had a recurring challenge on microsoft.vb.com for
at least 6 months for someone to provide code where VB fails to release
properly. No one has satisfied that challenge yet.
I can, however, relate to you several instances where reliance on setting to
Nothing to solve problems can lead to all kinds of wasted time and
misconceptions. Or better yet, search the archive of vb.com over Nov., Dec,
for the latest round of discussions.
Steven
Terry McKiernan wrote in message ...
>Is there a definitive answer as to whether or not you should set all
objects
>to Nothing explicitly at the end of their scope, i.e. either when exiting a
>function, terminating a class instance or shutting down a program? I have
>heard it both ways directly from MS Tech Support and in articles in
>magazines like VBPJ.
<snip>
Rob Nicholson
Yeah - we wish :-) A right old can of worms hiding under there mate!
Cheers, Rob.
Sjoerd Verweij
>really no way to *prove* that VB always releases--because you cannot prove a
>negative. However, I've had a recurring challenge on microsoft.vb.com for
>at least 6 months for someone to provide code where VB fails to release
>properly. No one has satisfied that challenge yet.
I could, but my previous employer would sue me. You'll have to take my
word for it: if you make your object structure sufficiently insane, VB
cannot clean it up.
Sjoerd Verweij
>Nothing to solve problems can lead to all kinds of wasted time and
>misconceptions.
Ever done a poll on how many VB6 programmers know about the
With-reference lunacy?
Steven A. Mitchell
solve the circular reference--then it will appear to satisy the challenge.
No programming solution can handle a fatal design flaw.
I'm surprised more people do not try that answer. For some reason, code
that supports that example is always really old, no longer available, yada,
yada, yada.
Excuse me if I continue to be skeptical :-)
Steven
Sjoerd Verweij wrote in message <3a54c724....@207.46.180.23>...
Jonathan Allen
C++: Objects declared in the stack. [1]
C++: Objects using the safe pointer that automatically handles the
refcounts. [2]
VB6: We rarely follow "Unload FormAbout" with "Set FormAbout = Nothing" [3]
VB.Net: We don't use "myInteger = Nothing", though it's perfectly valid. [4]
--
Jonathan Allen
Notes:
1: I don't think it's even possible
2: From what I understand, this has the same effect as VB6's references.
3: Where FormAbout is the name of the form, not a local variable.
4: Resets the structure to it's default value.
Sjoerd Verweij
>Aye, if you make the code so convoluted that no one will take the time to
>solve the circular reference--then it will appear to satisy the challenge.
The specific app I'm talking about didn't have design flaws -- it WAS
one. So was its initial programmer. I found a whole new realm of pure,
unadulterated hatred. It was so bad it needed a complete rewrite. PHB:
"why can't you just FIX it?"
>No programming solution can handle a fatal design flaw.
You are right -- with good design and coding, leaks due to circular
referencing can always be avoided. But there's a lot of code out there
that has it, and some so bad that it's easier to rewrite than to fix.
Steven A. Mitchell
Sjoerd Verweij wrote in message <3a54dd4f....@207.46.180.23>...
<snip>with good design and coding, leaks due to circular
>referencing can always be avoided. But there's a lot of code out there
>that has it, and some so bad that it's easier to rewrite than to fix.
Fair enough. So why not just fix the circular reference instead of assuming
that every module level variable is a potential circular reference?
Steven
Sjoerd Verweij
>Fair enough. So why not just fix the circular reference instead of assuming
>that every module level variable is a potential circular reference?
When it's somewhere in 43 classes spread across 3 projects and so bad
that debugging crashes your IDE every two minutes?
Steven A. Mitchell
Steven
Sjoerd Verweij wrote in message <3a54ec8b....@207.46.180.23>...
Sabba
?
I don't know if this bug is still around but my experience is better safe
then sorry
--
esab...@vb2themax.com
http://sabbadin.tripod.com
MTS VB-COM related FAQ: http://sabbadin.tripod.com/mts_faq
"Steffen Ramlow" <s.ra...@gmx.de> wrote in message
news:OUF99CXdAHA.2000@tkmsftngp04...
Michael (michka) Kaplan
ever said differently -- specifically, Matt did not say anything about this
being a bad idea.
What he DID say (and what is true) is that there is NO benefit to setting an
object variable to nothing explicitly rather than letting it go out of
scope, unless the freeing up resources early would be a good thing. For
example:
Sub Test
Dim con as Connection
' Do a ton of stuff with a connection
con.Close
Set con = Nothing
' Do a ton more stuff
End Sub
Now in this case, the Set to nothing is useful because ADO connection
objects have a lot of "stuff" in them and the explicit free rather than
leaving all that memory allocated for the rest of the proc may be silly.
HOWEVER, in the case where you are not doing a lot of stuff in the proc:
Sub Test
Dim con as Connection
' Do a ton of stuff with a connection
con.Close
Set con = Nothing
End Sub
Setting con to Nothing here makes no sense and IS About to happy anyway. So
setting to Nothing here does not make real sense.
--
MichKa
a new book on internationalization in VB at
http://www.i18nWithVB.com/
"Sabba" <sabb...@infinito.it> wrote in message
news:u5NsFiMeAHA.2132@tkmsftngp05...
Bob Butler
"Michael (michka) Kaplan" <forme...@spamfree.trigeminal.nospam.com> wrote
in message news:eSqVAnMeAHA.1208@tkmsftngp05...
<cut>
> What he DID say (and what is true) is that there is NO benefit to setting
an
> object variable to nothing explicitly rather than letting it go out of
> scope
as far as performance and functionality goes that is true
I add the set for 2 reasons:
1. it serves as an explicit visual reminder to me that the object is being
released and that any cleanup I need to do has to be done by that point. In
other words, if I see "set db=nothing" without seeing "db.Close" near it
then I'm missing something.
2. I often like to set a breakpoint on the Set and on the "end function"
line so I can walk through the terminate event of my objects and then catch
the execution before the procedure exits. If I need to make changes and/or
re-instantiate the object to try again I find it easier to work with when
I'm still in the procedure.
both are certainly just personal preference and coding style but the
explicit set does have value to me even if it does nothing for the running
application. If adding the Set had a negative effect then I'd skip it but
since it's essentially a zero for the app I do it for the small benefit I
get during maintenance coding.
Michael (michka) Kaplan
news:#CJ6keOeAHA.900@tkmsftngp04...
> If adding the Set had a negative effect then I'd skip it but
> since it's essentially a zero for the app I do it for the small benefit I
> get during maintenance coding.
Actually, as was mentioned by someone (Bill Storage I think, but it might
have been Matt) in vb.vb7 a while back that there IS a negative effect,
based on how the implicit and explicit cases are handled (after all, if you
explicitly so it that does not stop the need for another implicit check to
happen on teardown).
Maybe not enough to overcome the "psychological benefits", but it is worth
thinking about.
Sabba
connection explicitely
--
esab...@vb2themax.com
http://sabbadin.tripod.com
MTS VB-COM related FAQ: http://sabbadin.tripod.com/mts_faq
"Michael (michka) Kaplan" <forme...@spamfree.trigeminal.nospam.com> wrote
in message news:eSqVAnMeAHA.1208@tkmsftngp05...
Bob Butler
> "Bob Butler" <butl...@earthlink.net> wrote in message
> news:#CJ6keOeAHA.900@tkmsftngp04...
>
> > If adding the Set had a negative effect then I'd skip it but
> > since it's essentially a zero for the app I do it for the small benefit
I
> > get during maintenance coding.
>
> Actually, as was mentioned by someone (Bill Storage I think, but it might
> have been Matt) in vb.vb7 a while back that there IS a negative effect,
> based on how the implicit and explicit cases are handled (after all, if
you
> explicitly so it that does not stop the need for another implicit check to
> happen on teardown).
>
> Maybe not enough to overcome the "psychological benefits", but it is worth
> thinking about.
I am. I haven't decided if I'm going to carry forward with the explicit
releases for documentation purposes or not. Of course, I haven't decided
if I'm going to go to VB.Net at all yet either.
Michael (michka) Kaplan
inescapable, enough that I would offer a cash prize to you if you could
prove a reproducible case where the below argument is not true, and that
some bug was caused, thereby.
--
MichKa
a new book on internationalization in VB at
http://www.i18nWithVB.com/
"Sabba" <sabb...@infinito.it> wrote in message
news:evyJlVQeAHA.924@tkmsftngp05...
Rob Nicholson
assuming
> that every module level variable is a potential circular reference?
What do you mean by "fix circular references"? Circular references are not a
bug/problem - they're a frequently used mechanism that's perfectly
acceptable.
Cheers, Rob.
Steven A. Mitchell
Rob Nicholson wrote in message ...
Well, I disagree that using them "frequently" is not a design problem, but
yeah--there are valid times to use them :-) When I said "fix" them, I
should have said fix the release of the circular references. That was
somewhat implied by the context of the whole discussion, but I guess the
context was stretching a bit thin. As in, "fix" the circular references
that are actually circular--instead of assuming that every modular level
variable is a potential circular reference and pretending that setting them
to nothing will solve that issue.
Steven
Steven A. Mitchell
Bob Butler wrote in message <#cqzWNReAHA.952@tkmsftngp05>...
>> > If adding the Set had a negative effect then I'd skip it but
>> > since it's essentially a zero for the app I do it for the small benefit
>I
>> > get during maintenance coding.
>>
>> Actually, as was mentioned by someone (Bill Storage I think, but it might
>> have been Matt) in vb.vb7 a while back that there IS a negative effect,
>> based on how the implicit and explicit cases are handled (after all, if
>you
>> explicitly so it that does not stop the need for another implicit check
to
>> happen on teardown).
>>
>> Maybe not enough to overcome the "psychological benefits", but it is
worth
>> thinking about.
>
>I am. I haven't decided if I'm going to carry forward with the explicit
>releases for documentation purposes or not. Of course, I haven't decided
>if I'm going to go to VB.Net at all yet either.
Note that there is the other negative effect that occurs anytime you use
code for documentation: People (i.e. fellow developers, new guys,
maintenance folks, etc.) begin to believe that the code is necessary. In
addition to causing lengthy discussion like the one we are currently in, it
also leads directly to wasted development time. I have seen this time and
time again. For a striking example, simple check out the 1-4-01 discussion
"Dodgy Code" (turning out to be more aptly named than perhaps the author
intended :-)
A mere 2 days after this discussion started, someone asks how to stop memory
leaks. I've got two people essentially arguing with me that the guy needs
to set all of his references to nothing. (And yes, I did point to this
discussion.)
Steven
Sjoerd Verweij
>released
As long as you realize that (in VB6) _that might actually not be the
case_, you're fine. Especially junior programmers see the Set and
believe that no matter what, the object is gone.
Bob Butler
"Sjoerd Verweij" <sjo...@sjoerd.org> wrote in message
news:3a59f970....@msnews.microsoft.com...
better wording: an explicit visual reminder to me that I want the object to
be released
that's why I followed with comments about making sure any related cleanup
was done already.
Rob Nicholson
We have implement a parent-child object mechnism where circular references
are the norm. So for us, they're used all over the place.
> yeah--there are valid times to use them :-) When I said "fix" them, I
> should have said fix the release of the circular references. That was
Ah right - that's okay then :-)
Cheers, Rob.
Sjoerd Verweij
>be released
Okay. Sorry.