This question already has answers here:
new DateTime() vs default(DateTime)
(4 answers)
Closed 2 years ago.
if(new DateTime() == default(DateTime))
{
//blah blah...
}
Code 'new DateTime()' will create new instance and take some memory for itself.
I want to know is Code 'default(DateTime)' also create new instance and take some memory or just compare and then end
As stated here, it creates a new default value. So its same memory allocation as it happens for value type and reference type. First one on stack second on heap
https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/operators/default#default-literal
For value types, it sets to zero, e.g. default int is 0. For reference types default is null.
See the docs for details.
Since DateTime is a value type, it will be allocated on the stack, rather than the heap. It will only take up memory inside the current stack frame, or if it is a member of a class.
Related
This question already has answers here:
Why are structs stored on the stack while classes get stored on the heap(.NET)?
(10 answers)
Closed 5 years ago.
I heard that variables are stored in stack and objects are stored in heap.
If i declare variable as var password= "abc".Now where this password is going to store(heap /stack)
Where an object is stored is not something you should be worrying about in the general case, but, as everytime this question crops up in SO, commentaries and answers crop up spreading the mythical and false belief that value types are stored in the stack and reference types are stored in the heap. No, no and no!
Thnink of it this way, its better: reference types go on the heap, short lived value types go on the stack. Long lived value types (fields, captured variables in a closure) go on the heap. The storage mechanism has very much to do with the expected lifetime of a variable, its not all about the nature of the type of the variable.
If you really want to know the details, read this.
This question already has answers here:
Why do local variables require initialization, but fields do not?
(4 answers)
Closed 6 years ago.
This code:
int a;
if(a==1){ do something}
or
Image img;
if(img!=null){do something}
These codes generates the error:
Use of unassigned local variable 'variable-name'
I know what exactly this error says and how to resolve it. but what I wonder is that
Shouldn't a variable that is declared and not assigned a value, have a value? like null for the Image
2.Why wouldn't it allow to even compare the variable? it can simply say that it doesn't match.
Shouldn't a variable that is declared and not assigned a value, have a value? like null for the `Image'
No. That's just not the way the language is defined. Local variables do not have default values in C# (or most other languages, but by no means all).
2.Why wouldn't it allow to even compare the variable? it can simply say that it doesn't match.
Because you're trying to read the value of a variable that you've never assigned a value to, which is a bug (in C#) by definition. Thus, it's calling your attention to that bug.
This question already has answers here:
Programmatic equivalent of default(Type)
(14 answers)
Closed 8 years ago.
So, I need to retrieve all properties of an instance which currently have a value that matches the default value of their respective type. Something along the lines of
GetType().GetProperties().Where(x =>
x.GetValue(this).Equals(default(x.PropertyType)));
This obviously doesn't work because it seems 'x' cannot be resolved anymore at this point. What could I do?
The problem is slightly different. You cannot pass a runtime instance of Type to default. Your problem can be simplified to this:
var type = typeof (string);
var defaultValue = default(type); // doesn't work
That doesn't work. Instead, you want to get the default value at run time, which has been answered by this question.
This question already has answers here:
Setting Objects to Null/Nothing after use in .NET
(15 answers)
Closed 8 years ago.
I don't mean to start a[nother] civil war over this issue, but should nullification be enforced or not?
While trying to fix a bug (that was fixed elsewise, as can be seen here), I added code like this in a couple of places to immediately and explicitly set some objects to null:
List<String> XMLFiles = CCRUtils.GetXMLFiles(fileType, #"\");
foreach (string fullXMLFilePath in XMLFiles)
{
RESTfulMethods.SendXMLFile(fullXMLFilePath, uri, 500);
}
XMLFiles = null;
Now that I know that did not solve the problem I was having, should I just leave it, or remove this type of code?
should nullification be enforced or not?
In general, it should not. There are very few circumstances where there is a reason to set a variable to null. As soon as the scope in which the variable is declared ends, the reference to the object will no longer be held.
Setting a variable to null after use is (almost) always just a misunderstanding of how the GC works, and serves no purpose.
This question already has answers here:
What's the difference between the 'ref' and 'out' keywords?
(28 answers)
Why ref and out in C#?
(7 answers)
Closed 9 years ago.
As per this post, the reason there is a distinction between ref and out is because it is costly to copy the value of the variable when using ref.
Why is there a need to marshall in the first place? Doesn't C# just pass the pointer under the hood? In that case, there would be no need to copy values.
Because the semantics of the two are completely different.
An out parameter is used to indicate that it will be used to return (output) a value, nothing more.
A ref parameter on the other hand indicates that an existing object (variable) should be passed to the method by reference. In the context of C#, an object passed by reference (not to be confused by reference types) is often a hint that the method will (and should) modify that object. It shouldn't be used "just because." It is generally used only for value types since it is the only way to get reference semantics for them.