Simple... The key is the way you pass the reference to ChangeClass.
When you do ChangeClass(tc), you're only sending a reference to tc... You're telling ChangeClass where, in memory, it can find the data in tc. And since you didn't specify the ref keyword when passing it to ChangeClass, you're just sending a COPY of the reference, not the original variable.
As an analogy... I have the URL to a website, and I e-mail it to you. You erase your e-mail, but you haven't erased my copy of the URL, just your own.
Thanks, that very much clears the doubt.
Please see what I got is correct:
I have a reference stored to the object of the TestClass on the stack. When I pass this to the method ChangeClass, I just pass a value which refers to a memory location which is same as the actual memory location of the object. So any change to the fields of the class is reflected as the method is accessing the same memory location. When I assign the object null in the method, the reference to the object is no more available to the method. But it is still available to the Main method.
This is my understanding. Please let me know if I am wrong somewhere.
Thanks and voted as a "good answer".
PS: I am changing the message type to answer as it contains descriptive answer.
mmm, you're not rendering the class itself to null I think, rather the parameter tc.
Since it is a reference it should be the same object, but maybe .Net does something funky when the parameter passed to a method is the same type as the class.
I don't know for sure, but it could be. Try passing the object with the ref keyword (need to change method signature as well).
No issue, it works ok, but I'm a bit old fashioned and come from a point of view where simplicity always wins the day. Just little things like why are we using static Array.ForEach when the language provides 'built in' support for such things. Also, if I remember back, doesn't every delegate result in a whole class being generated behind the scenes at MSIL level. Isn't there a performance hit associated with invoking a delegate?
Although there's nothing wrong with it as such, why do it this way? It just has a ring of macho programming about it.
Well, I'd argue that its more readable and readily understandable being spread over several lines (it makes the execution flow clearer), and the local variable you have removed could be something useful to hover over when debugging.
There's nothing wrong with the code, I'm not saying that, but I think it can be expressed more clearly and would be easier to debug done the traditional way and I'm trying to gauge whether people agree with me or not.
I'm sure that everyone has their own opinion on "to variable, or not to variable". Personally, I never create one-time-only variables: I only establish them if they need to persist, or if I need to use them more than once. (And honestly, "readability" is never an argument that holds water for me, I've seen it used to defend bad practices in the past.)
If only somebody would invent a mechanism to find information on this cluttered mess we call the internet. By golly, they'd make a fortune. I take it you're hoping that we have stumbled across some nugget of information that provides the answer.
By randomly typing words into the browser address bar, I managed to find this page[^] in seconds. I must be some form of savant.
I know exactly what you mean, I've even been giving it a bit of a break recently.
The quality of the questions has been low recently, and some claque-y voting for articles etc. The CP has been consistently been the best .net forum for the 10ish years I've been developing, but I'm not confident that will continue to be the case in the next few years unless things improve substantially & soon.