Setting objects = Nothing
BurtonRoberts
before exiting the procedure. In VB.net, is this considered still necessary,
and should I now set all string variables = nothng as well since they are
derived from system.object?
Thanks in advance,
and sorry about cross-posting
Burton Roberts
Cali LaFollett
It is optional. Scoping rules for the most part still work as they always
have except for "block" level variables which are new to VB.NET.
In all actuality in VB or VBA, you don't need to set your objects to Nothing
before exiting a procedure. That is automatically done for you for all
procedure level variables at the exiting of the procedure.
You actually invoke undo overhead as the compiler does checks at the exiting
to see if it needs to release your objects. You are actually performing the
operation twice by setting them to nothing before exiting.
Of course, if you feel that it makes your code more explicit and
understandable to do this, then the overhead endured by the additional
setting to Nothing should go unnoticed.
Hope this answers your question.
--
Regards,
Cal
"BurtonRoberts" <Burton...@ims.msn.com> wrote in message
news:OAbj7PKPBHA.1452@tkmsftngp04...
David Yuan
have finished using it. Although VB will release the object automatically
for you according the the scoping rules, setting them to Nothing explicitly
will make them available to Garbage collection earlier, which is good for
resource recycling. In setting the objects to Nothing explicitly makes your
code looks cleaner.
However, you don't have to set the String variables to Nothing. Since
unless they are boxed, String variables are value types and you can use
them just like Integer and Long.
Willy Denoyette
Willy.
"David Yuan" <davyuan...@microsoft.com> wrote in message news:EW2cfdP...@cppssbbsa01.microsoft.com...
Cali LaFollett
> > unless they are boxed, String variables are value types and you can use
> > them just like Integer and Long.
String types are also AFAIK unique to any other data type in that they are
immutable. Meaning that once you create a String it remains, under the
cover, the same object as long as you never modify that String. Once you
change a String in any little way, .NET literally creates new strings under
the cover and assigns your attaches this "new" string to your string
variable.
In other words once created you cna NEVER change it. But there is always the
.NET String builder class which allows you to build strings without the
above mentioned limitations.
--
Regards,
Cal
Mark
(at most).
I don't do it, it's not necessary, there's no benefit, but you can if you
like. All the rest is opinion.
"David Yuan" <davyuan...@microsoft.com> wrote in message
news:EW2cfdP...@cppssbbsa01.microsoft.com...
Cali LaFollett
This....
>>Strings are Reference types NOT value types, they do
>>have value semantics, but a string can't be 'boxed/unboxed'.
...goes with this...
> String types are also AFAIK unique to any other data type in that they are
> immutable. Meaning that once you create a String it remains, under the
> cover, the same object as long as you never modify that String. Once you
> change a String in any little way, .NET literally creates new strings
under
> the cover and assigns your attaches this "new" string to your string
> variable.
>
> In other words once created you cna NEVER change it. But there is always
the
> .NET String builder class which allows you to build strings without the
> above mentioned limitations.
Sorry!
--
Regards,
Cal
Gregor R. Peisker
> Strings are Reference types NOT value types, they do have value semantics, but
a string can't be 'boxed/unboxed'.
Strings cannot be boxed; boxing applies to values types only. The String is a
reference type, since it derives directly from System.Object.
Whether the String type follows value semantics is debatable. Clearly it's a
reference type, but since a string is constant (immutable), every "manipulation"
of it leads up to assigning newly created String objects to the reference
variables. The following looks like the String was a value type (the
reference equality test aside):
Dim a, b As String
a = "One"
b = a
Console.WriteLine(String.ReferenceEquals(a, b)) ' True
Console.WriteLine(a) ' "One"
Console.WriteLine(b) ' "One"
b = "Two"
Console.WriteLine(a) ' "One"
However, make no mistake about the assignment operator: it's used for assigning
values as well as references. And the string literal "Two", well, I think it's
best to just see it as a piece of source code, not as a value. What the
expression in the third line does is create a new instance and assign it to the
reference. The string literal is more like an "object literal" (somewhat
inexact). If VB.Net still had the "Set" statement, we'd write:
Set b = "Two"
So the fact that we can assign a literal, using the "=" operator really proves
nothing. To make it more obvious, let's switch to C:
char * psz;
psz = "BSTR?";
Clearly, a char * is not a value type like VB6's String. Although this code
fragment might look like it.
Gregor
Jonathan Allen
> (at most).
If it is a long running function or the class is very large, then it could
matter a lot. However, In the general case I wouldn't bother.
Another point is that explicitly setting things to nothing clutters up the
code. Thus making it harder to locate missing Dispose calls, which are
important.
--
Jonathan Allen
"Mark" <ma...@somewhere.com> wrote in message
news:u28Tw2SPBHA.2048@tkmsftngp04...
BurtonRoberts
Thanks to all who have responded. I'm going with the consensus, not to
bother. What a relief!
Burton Roberts
Cali LaFollett
> bother. What a relief!
Not a prob! <g>
With all of these changes, it's nice to be able to find the answers. I know
I have figured out some problems here. Nice to be able to do the same for
others if I can.
Cal
Bob Butler
"Jonathan Allen" <grey...@cts.com> wrote in message
news:u3qFrpUPBHA.1600@tkmsftngp03...
> > Yep, they'll be available to the GC a couplea machine instructions
earlier
> > (at most).
>
> If it is a long running function or the class is very large, then it could
> matter a lot. However, In the general case I wouldn't bother.
FWIW, according to a recent thread on the DevX mailing list it is possible
for the GC to collect objects that have not been explicitly released if the
JITter has determined that the object is not referenced from the current
execution point to the end of the scope. That makes it even less required.
> Another point is that explicitly setting things to nothing clutters up the
> code. Thus making it harder to locate missing Dispose calls, which are
> important.
I have exactly the opposite viewpoint -- explictly settign things to nothign
makes the code much clearer and reduces maintenance headaches since I never
have to wonder if the original developer still needed the reference or knew
it was going out of scope. Also, by searching for the Nothing keywords I
can locate where the Dispose calls are needed much faster than having to
work through every procedure line by line.
Jonathan Allen
> can locate where the Dispose calls are needed much faster than having to
> work through every procedure line by line.
While that method does make sense, it has its flaws. The problem I see with
that is you have to read the code to determine if the object should be
disposed. Otherwise you may close a global resource that the programmer just
happened to have a local reference to.
The method I plan using, when combined with your idea, would account for
that flaw.
Variables that need to be disposed use the prefix "xo" instead of the
standard "o". Only variables that need to be disposed IN THAT FUNCTION get
the xo prefix. This form of self-documentation takes care of the problem
that you may accidentally dispose something that you should have left open.
--
Jonathan Allen
"Bob Butler" <butl...@earthlink.net> wrote in message
news:e4BbX#VPBHA.392@tkmsftngp04...
Michael (michka) Kaplan
> Variables that need to be disposed use the prefix "xo" instead of the
> standard "o". Only variables that need to be disposed IN THAT FUNCTION get
> the xo prefix. This form of self-documentation takes care of the problem
> that you may accidentally dispose something that you should have left
open.
Wow! Jonathan Allen proposes Neo-Hungarian. Cool!
--
MichKa
Michael Kaplan
(principal developer of the MSLU)
Trigeminal Software, Inc. -- http://www.trigeminal.com/
the book -- http://www.i18nWithVB.com/
Joe "Nuke Me Xemu" Foster
> "Jonathan Allen" <grey...@cts.com> wrote in message
> news:u3qFrpUPBHA.1600@tkmsftngp03...
> > > Yep, they'll be available to the GC a couplea machine instructions
> earlier
> > > (at most).
> >
> > If it is a long running function or the class is very large, then it could
> > matter a lot. However, In the general case I wouldn't bother.
>
> FWIW, according to a recent thread on the DevX mailing list it is possible
> for the GC to collect objects that have not been explicitly released if the
> JITter has determined that the object is not referenced from the current
> execution point to the end of the scope. That makes it even less required.
What happens if the no-longer-referenced object is some sort of container
for objects which are still in use, and shutting down the container would
affect the contained objects? Perhaps the prematurely collectable object
is some sort of persistence manager which holds a file open on behalf of
other objects, which may not have circular references back to the manager
object. If the manager's collected before the other objects are even in
their final state...
More of the same from the minds who brought us End While. Feh.
--
Joe Foster <mailto:jlfoster%40znet.com> Auditine Addict <http://www.xenu.net/>
WARNING: I cannot be held responsible for the above They're coming to
because my cats have apparently learned to type. take me away, ha ha!
Bob Butler
> > Also, by searching for the Nothing keywords I
> > can locate where the Dispose calls are needed much faster than having to
> > work through every procedure line by line.
>
> While that method does make sense, it has its flaws. The problem I see
with
> that is you have to read the code to determine if the object should be
> disposed. Otherwise you may close a global resource that the programmer
just
> happened to have a local reference to.
>
> The method I plan using, when combined with your idea, would account for
> that flaw.
>
> Variables that need to be disposed use the prefix "xo" instead of the
> standard "o". Only variables that need to be disposed IN THAT FUNCTION get
> the xo prefix. This form of self-documentation takes care of the problem
> that you may accidentally dispose something that you should have left
open.
I already use scoping and type prefixes that would take care of virtually
all cases. It's usually pretty obvious from a cursory glance at the code if
the object can be disposed or not. In a few cases more in-depth checks
would be needed. Also, I was talking about existing VB6 code that is being
ported into VB.Net; since I already have the =Nothing in almost every case
it's easy to at least find the places where dispose MIGHT be needed.
Patrick Steele
Foster" <j...@bftsi0.UUCP> <"Joe \"Nuke Me Xemu\" Foster"
<j...@bftsi0.UUCP>>),
> What happens if the no-longer-referenced object is some sort of container
> for objects which are still in use, and shutting down the container would
> affect the contained objects? Perhaps the prematurely collectable object
> is some sort of persistence manager which holds a file open on behalf of
> other objects, which may not have circular references back to the manager
> object. If the manager's collected before the other objects are even in
> their final state...
If I understand correctly, you're saying you have a "container" object
and you add "sub objects" to the container (intentionally). Later on,
you're done with the container and set it's reference to nothing. If
you're going to dump your container, I think it's implicit that you're
also done with the sub-objects.
If these sub-objects are holding resources, then you have a container
that needs to be designed with this in mind. It should have some kind
of a cleanup (Dispose) method.
--
Patrick Steele
Joe "Nuke Me Xemu" Foster
> In article <O$UHS3XPBHA.2108@tkmsftngp05> (from "Joe \"Nuke Me Xemu\"
> Foster" <j...@bftsi0.UUCP> <"Joe \"Nuke Me Xemu\" Foster"
> <j...@bftsi0.UUCP>>),
> > What happens if the no-longer-referenced object is some sort of container
> > for objects which are still in use, and shutting down the container would
> > affect the contained objects? Perhaps the prematurely collectable object
> > is some sort of persistence manager which holds a file open on behalf of
> > other objects, which may not have circular references back to the manager
> > object. If the manager's collected before the other objects are even in
> > their final state...
>
> If I understand correctly, you're saying you have a "container" object
> and you add "sub objects" to the container (intentionally). Later on,
> you're done with the container and set it's reference to nothing. If
> you're going to dump your container, I think it's implicit that you're
> also done with the sub-objects.
No. Why don't you try reading the message to which I was replying:
"FWIW, according to a recent thread on the DevX mailing list it is possible
for the GC to collect objects that have not been explicitly released if the
JITter has determined that the object is not referenced from the current
execution point to the end of the scope. That makes it even less required."
-- Bob Butler in news://msnews.microsoft.com/e4BbX#VPBHA.392@tkmsftngp04
> If these sub-objects are holding resources, then you have a container
> that needs to be designed with this in mind. It should have some kind
> of a cleanup (Dispose) method.
No, I'd need a container that can tell the JITter to keep its filthy paws
off of it, the damned dirty ape!
--
Joe Foster <mailto:jlfoster%40znet.com> Space Cooties! <http://www.xenu.net/>
Patrick Steele
<j...@bftsi0.UUCP>>),
>
> for the GC to collect objects that have not been explicitly released if the
> JITter has determined that the object is not referenced from the current
> execution point to the end of the scope. That makes it even less required."
> -- Bob Butler in news://msnews.microsoft.com/e4BbX#VPBHA.392@tkmsftngp04
So if the object isn't referenced anymore, it's available for garbage
collection. This is not new. Why do you see this as a problem?
> No, I'd need a container that can tell the JITter to keep its filthy paws
> off of it, the damned dirty ape!
That's "stinking paws" (1968 version). Haven't seen the new one yet.
--
Patrick Steele
Joe "Nuke Me Xemu" Foster
> In article <#jJAqDZPBHA.1496@tkmsftngp03> (from "Joe \"Nuke Me Xemu\"
> Foster" <j...@bftsi0.UUCP> <"Joe \"Nuke Me Xemu\" Foster"
> <j...@bftsi0.UUCP>>),
> >
> > "FWIW, according to a recent thread on the DevX mailing list it is possible
> > for the GC to collect objects that have not been explicitly released if the
> > JITter has determined that the object is not referenced from the current
> > execution point to the end of the scope. That makes it even less required."
> > -- Bob Butler in news://msnews.microsoft.com/e4BbX#VPBHA.392@tkmsftngp04
>
> So if the object isn't referenced anymore, it's available for garbage
> collection. This is not new. Why do you see this as a problem?
And you DevX.NET people claim *I* have the reading comprehension problem?
Re-read the second line: "collect objects that have NOT been EXPLICITLY
RELEASED" [emphasis mine] Presumably, this means that the JITter might
implicitly and silently release objects even before they go out of scope,
if they are no longer explicitly being used in the code! Perhaps you can
comprehend pseudo-code:
sub oopstheydiditagain ()
dim stooges as persister
stooges = new persister
dim larry as stooge, curly as stooge, moe as stooge, shemp as stooge
larry = new stooge
curly = new stooge
moe = new stooge
shemp = new stooge
stooges.add(larry)
stooges.add(curly)
stooges.add(moe)
stooges.add(shemp)
moe.poke(larry)
curly.runaround()
' etc etc etc
end sub
With me so far? Yeah, right... Anyway, let's say that the above pseudocode
no longer uses the stooges reference explictly after adding the four stooge
objects. If what Bob said is correct, the JITter might feel free to slip in
a "stooges = nothing" immediately after the last explicit use of "stooges".
What could possibly go wrong, I ask you?
> > No, I'd need a container that can tell the JITter to keep its filthy paws
> > off of it, the damned dirty ape!
>
> That's "stinking paws" (1968 version). Haven't seen the new one yet.
I haven't seen the "reinterpretation", either.
--
Joe Foster <mailto:jlfoster%40znet.com> "Regged" again? <http://www.xenu.net/>
Gregor R. Peisker
> Variables that need to be disposed use the prefix "xo" instead of the
> standard "o". Only variables that need to be disposed IN THAT FUNCTION get
> the xo prefix. This form of self-documentation takes care of the problem
> that you may accidentally dispose something that you should have left open.
the problem I see with relying on a naming convention - for that purpose - is
that you have to know that an object needs disposing in the first place. But If
you know that, you can write the Dispose() call right away as well.
Gregor
Ronald Laeremans [MSFT]
cleaning it up?
Ronald Laeremans
Visual C++ compiler team
"Joe "Nuke Me Xemu" Foster" <j...@bftsi0.UUCP> wrote in message
news:O4rSH4aPBHA.1804@tkmsftngp04...
Joe "Nuke Me Xemu" Foster
> If nothing refers to stooges directly or indirectly, what is unsafe in
> cleaning it up?
Why do I even bother anymore?
<news://msnews.microsoft.com/O$UHS3XPBHA.2108@tkmsftngp05>
--
Joe Foster <mailto:jlfoster%40znet.com> L. Ron Dullard <http://www.xenu.net/>
Bob Butler
"Ronald Laeremans [MSFT]" <ronl...@microsoft.com> wrote in message
news:#HWGlqiPBHA.1404@tkmsftngp03...
> cleaning it up?
Absolutely nothing in most case, as long as the determination includes
possible references from finalizer code so that there is no chance that such
an "early-terminated" object could possibly be referenced in any way after
it is killed. I was mostly just surprised that the JITter might go to that
level of analysis and thought it should be mentioned as part of the
discussion about if/when explicit object release is needed. In the long run
I'll have to see how it works in practice and experiment with possible ways
to fool the JIT process into doing it prematurely so as to learn what to
avoid.
BTW, from what I understand the JITter does not insert any "set o=Nothing"
code, it's more that the GC process can identify that the object reference
will never be looked at again so it can be treated as released. (a
Schroedinger's object if you will)
Joe "Nuke Me Xemu" Foster
What happens if this Schroedinger's object has a Dispose method? What
if the Dispose method has side-effects? I think it's a train-wreck
waiting to happen, like the rest of TEOVBAWKI.NET.
--
Joe Foster <mailto:jlfoster%40znet.com> Greed = God? <http://www.xenu.net/>
Jonathan Allen
is
> that you have to know that an object needs disposing in the first place.
But If
> you know that, you can write the Dispose() call right away as well.
This is mainly documentation for the next guy to work on the code. So they
don't say "Oh, that class can be disposed! I better add it in!".
As for writing the Dispose call right away, that is rarely an option. It
usually has to be at the end of an error handling block in order to
guarantee that it is called.
--
Jonathan Allen
"Gregor R. Peisker" <gre...@peisker.de> wrote in message
news:umPCy2cPBHA.1548@tkmsftngp03...
Ronald Laeremans [MSFT]
liveness information. There is no need to set references to null.
The Jit doesn't do extremely complex analysis for this. Just in the case
that it is easily determinable that there are no side effects of any kind is
this shortening of lifetime optimization done.
So Joe, how many bug reports have you submitted on this or any other topic.
Specifically for this one, I would be interested, since I worked on this
area 18 months ago.
Ronald Laeremans
Visual C++ compiler team
"Joe "Nuke Me Xemu" Foster" <j...@bftsi0.UUCP> wrote in message
news:#X47QljPBHA.1556@tkmsftngp05...
Joe "Nuke Me Xemu" Foster
> A Jit constructs range tables for the GC that contain the local variables
> liveness information. There is no need to set references to null.
>
> The Jit doesn't do extremely complex analysis for this. Just in the case
> that it is easily determinable that there are no side effects of any kind is
> this shortening of lifetime optimization done.
So now we know what it takes to drag concrete information out of you.
> So Joe, how many bug reports have you submitted on this or any other topic.
> Specifically for this one, I would be interested, since I worked on this
> area 18 months ago.
So you demand that I willfully and flagrantly pirate the intellectual
property of Microsoft Corporation? Why don't you ask me to disclose
the results of some benchmark test while you're at it, weasel-boy?
Or have you forgotten all about how you bravely ran away, away, from
our little chat about error handling, oh brave, brave, Sir Ronald?
1. "(b) Feedback. In the event Recipient provides feedback to Microsoft,
including but not limited to usability, bug reports and test results,
with respect to the Product testing all such feedback shall be the
property of Microsoft and may be used by Microsoft for any purpose."
-- Microsoft .NET Framework SDK Beta 2 EULA
http://msdn.microsoft.com/Downloads/eula_dotNETFrameworkSDK_Beta2.htm
Patrick Steele
<j...@bftsi0.UUCP>>),
>
> dim stooges as persister
> stooges = new persister
>
> dim larry as stooge, curly as stooge, moe as stooge, shemp as stooge
> larry = new stooge
> curly = new stooge
> moe = new stooge
> shemp = new stooge
>
> stooges.add(larry)
> stooges.add(curly)
> stooges.add(moe)
> stooges.add(shemp)
>
> moe.poke(larry)
> curly.runaround()
> ' etc etc etc
>
> end sub
>
> With me so far? Yeah, right... Anyway, let's say that the above pseudocode
> no longer uses the stooges reference explictly after adding the four stooge
> objects. If what Bob said is correct, the JITter might feel free to slip in
> a "stooges = nothing" immediately after the last explicit use of "stooges".
> What could possibly go wrong, I ask you?
First off, you mention a good point "If what Bob said is correct". I
ask you, is it correct? Can you give me a code sample that would show
the effects your describing?
I'm also thinking the other objects won't be destroyed because they
aren't available for garbage collection -- there's still a reference to
them via the larry, curly, more and shemp variables.
--
Patrick Steele
Ronald Laeremans [MSFT]
ran away from.
What specific right do you not want Microsoft to have about the bug you
submitted. We are always willing to work on an NDA basis for any
confidential information you need to give us to report a bug. Of course we
need the rights to fix the bugs and improve the product based on the
feedback customers give. Otherwise feedback wouldn't do much good, would it.
Anyway, I can hardly see why you would need anything of special value in a
bug report about the liveness range code in the Jit.
I still haven't gotten an email from you, so I can only assume that you have
no interest in getting permission to publish benchmark results for .NET
based on Beta 2 code and all your shouting, including the repeated reference
here about benchmark results is just hollow posturing.
-Ronald-
"Joe "Nuke Me Xemu" Foster" <j...@bftsi0.UUCP> wrote in message
news:u$PnDSkPBHA.1532@tkmsftngp03...
Gregor R. Peisker
> As for writing the Dispose call right away, that is rarely an option. It
> usually has to be at the end of an error handling block in order to
> guarantee that it is called.
Of course. I meant write the code for that "right away", not place the call
after the object creation statement.
Gregor
Bob Butler
"Patrick Steele" <pst...@ipdsolution.com_> wrote in message
<cut>
> First off, you mention a good point "If what Bob said is correct". I
> ask you, is it correct? Can you give me a code sample that would show
> the effects your describing?
This is where I heard about this possibility:
http://discuss.develop.com/archives/wa.exe?A2=ind0108E&L=DOTNET&P=R4738&D=0
Joe "Nuke Me Xemu" Foster
If, as has been claimed here, no objects are prematurely collected if
doing so might have side-effects, how did Brent discover that this was
in fact being done at all? I suppose he must have set a breakpoint
towards the end of the code and found that some of his references were
no longer valid.
--
Joe Foster <mailto:jlfoster%40znet.com> Sign the Check! <http://www.xenu.net/>
Apoorva Tiwari
Cali says that compiler inserts "object = nothing" code ...
someone else says that setting "object = nothing" makes it faster for GC to collect the object.
Which one is correct? Should I do the "object = nothing" in my code or is "object.Dispose()" sufficient.
Also, I think there is a concept of a WeakReference in which an object can be set to nothing and u hope that the GC does not collect it before u use it in ur own code. Am I on the right lines. Also, I wud like to know the utility of the same.
Warm Regards,
Apoorva Tiwari
Tata Consultancy Services
Website www.tcs.com
*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!
Bob Butler
"Apoorva Tiwari" <apoorva...@seepz.tcs.co.in> wrote in message
news:#eBgdM0PBHA.2368@tkmsftngp04...
> I am confused!!!!!
welcome to the club.
> Cali says that compiler inserts "object = nothing" code ...
That is incorrect.
> someone else says that setting "object = nothing" makes it faster for GC
to collect the object.
That is apparently true for debug builds if the procedure runs for an
extended period after you explicitly free the object. It is not necessarily
true in release builds of your application as it is possible for the JIT
compiler to determine that an object reference will not be used again before
it does go out of scope and make it available for the GC. It acts as if the
compiler inserted "object=nothing" code, although that's not technically
what is happening. (at least that's my understanding at this point)
> Which one is correct? Should I do the "object = nothing" in my code or is
"object.Dispose()" sufficient.
In most cases .Dispose is likely to be sufficient; in the case of procedures
that are done with an object but which will run for some time afterwards I'd
still use "object=Nothing" early in the procedure to release it during debug
builds and so that maintenance programmers can see your intentions clearly.
Personally, I will still use "object=Nothing" even when the reference is
going out of scope because I find value in it for debugging and for
maintenance work even though it is not strictly necessary.
> Also, I think there is a concept of a WeakReference in which an object can
be set to nothing and u hope that the GC does not collect it before u use it
in ur own code. Am I on the right lines. Also, I wud like to know the
utility of the same.
Yes, you can use weak references; before using them you must convert them
back to a strong reference and see if you get the object or Nothing. An
example would be an application that builds a list (of customers, files,
whatever) for the user to select from and the process of building the list
takes time and the list itself is relatively large and the user does not
need the list very often. In cases like that, once the user selects you can
get a weak reference to the list object and release string references. If
the system needs memory later on it is free to flush it. If you need the
list again you can check the reference and use it if it is still OK or
rebuild if not.
Cali LaFollett
>
> That is incorrect.
In the context of the original post by BurtonRoberts, "object = nothing" is
correct as in:
Public Sub MySub()
Dim oObj As SomeObject
'do some stuff here that uses oObj
End Sub
^^^^^^
The compiler will automatically set oObj to nothing here. This DOESN'T take
care of Dispose though. These are the same scoping rules that VB6 has. That
part has not changed.
--
Regards,
Cal
Ronald Laeremans [MSFT]
reference to null.
Ronald Laeremans
Visual C++ compiler team
"Cali LaFollett" <ca...@No-Spam-Please-visionized.com> wrote in message
news:O$9yR$7PBHA.1900@tkmsftngp03...
Cali LaFollett
> reference to null.
My apologies. The underlying techniques used to destroy an object going out
of scope have changed. No more hidden calls to Add and Remove Ref and other
little tricks that the VB6 compiler put in place.
This still does not change the fact that one does not have to explicitly set
a variable to nothing as it goes out of scope. In essence, scoping does make
it *appear* as if the variable is being set to null.
--
Regards,
Cal
Jonathan Allen
> after the object creation statement.
I can't write from both the top and bottom at the same time without losing
my place, can you?
--
Jonathan Allen
"Gregor R. Peisker" <gre...@peisker.de> wrote in message
news:OmgchprPBHA.692@tkmsftngp04...
Joe "Nuke Me Xemu" Foster
> > I meant write the code for that "right away", not place the call
> > after the object creation statement.
>
> I can't write from both the top and bottom at the same time without losing
> my place, can you?
So you're saying that it's fairly likely TEOVBAWKI programmers will forget
to call Dispose explicitly, since they are unworthy of "using" statements,
giving rise to "Heisenbugs" when working with scarce resources? The "B#"
team must have been really stoned on more than just *one* day, no?
--
Joe Foster <mailto:jlfoster%40znet.com> On the cans? <http://www.xenu.net/>
Gregor R. Peisker
> I can't write from both the top and bottom at the same time without losing
> my place, can you?
Sure. I start like this:
Sub UseResource()
Dim xo As ExpensiveObject()
Try
xo = New ExpensiveObject()
Catch
Finally
If Not xo Is Nothing Then xo.Dispose()
End Try
End Sub
Later, I add the code in between.
Gregor
Bob Butler
> Hi Jonathan,
>
> > I can't write from both the top and bottom at the same time without
losing
> > my place, can you?
>
> Sure. I start like this:
Same here. I always write any necessary cleanup code, or at least mark
where it will have to happen, immediately after adding any code that
allocates any resource. It makes it much harder to miss something and
becomes second nature very quickly.