Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
My question is what happen in memory when we create two object for one class variable.
For example:
class a = new class();
a = new class();
At that time, are both allocated in same memory
Two objects are allocated on the heap. The first one is replaced by the one from the second statement, and will be deallocated by the garbage collector when there's sufficient memory pressure that necessitates a collection.
class a = new class();
This will create two things: an instance of the class on the heap, and a reference a to that instance.
a = new class();
This will create a new instance of the class on the heap, and change the reference a to point to the new instance. The previous instance will remain in memory but be inaccessible without any other reference to it (aka. refcount of 0) and will be cleaned up by the garbage collector when it runs.
Related
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed last month.
Improve this question
I need a buffer of memory which holds actual objects, not references, in memory.
I am using Unity Engine for my app. In order to submit a draw-call in Unity, one must provide a Mesh-object and Material-object in the function call. Here
is the part of my algorithm I am trying to optimize.
Mesh[] meshes;
Material[] materials;
Foreach (mesh-type)
DrawMeshInstancedIndirect(mesh[i],material[i]...etc);
I want to be able to iterate over a buffer of memory directly containing the object data, with no references, because I don't want to fill my cpu cache with useless data fetching each object in random parts of memory. You cannot substitute structs for these special Unity classes.
It doesn't matter if it is bad practice or a very messy solution. This is a performance-critical part of my app where structs cannot be substitute for classes.
Here is a reference to the draw-call function, for more context.
https://docs.unity3d.com/ScriptReference/Graphics.DrawMeshInstancedIndirect.html
Try the fixed keyword.
class Foo
{
public int[] stuff = new int[999];
public unsafe void ExamplePinned()
{
fixed (int* pStuff = stuff)
{
//Alright, the data array is all set and ready to go. Think of 'pStuff' as a pointer
//to the first element in the array. You can use it to access the memory of the
//array and copy it to another buffer
}
}
}
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 4 years ago.
Improve this question
I have had trouble wrapping my head around this and it seems to have lack luster documentation.
For example, this code:
private static readonly Object obj = new Object();
Can someone parse through this code and explain what is happening here. What exactly are the properties of this new object that was created? Why create an object this way?
You create a new oject with the type of Object. In most cases a statement like this is used for locking purpuse, see https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/lock-statement for more information.
It simply creates an object of a type Object, which is the base type for all of C# reference types.
I has 4 methods:
ToString()
GetHashCode()
GetType()
Equals()
Every class derives form Object, so it has all of the methods above.
Moreover, 3 of these methods are virtual (so you can override them):
ToString()
GetHashCode()
Equals()
It's sometimes used for locking as Isitar mentioned in his answer.
Object obj
that declares a variable of type Object
= new Object();
the equals sign is assignment, the new operator creates a reference to a new instance of class Object and the portion of Object() default initializes it.
it will have the default properties of an object.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I have an IDisposable class A. I need to use an object of A inside another method M of class B. Method M is called multiple times (million times a day). Should I use local object of A inside M and dispose once done or should I declare class level static member inside B and dispose once application ends.
Let me know if I am not clear.
One object for the life of the application is a Singleton; while they are useful under specific circumstance, they are not generally a good idea. See this question for a detailed explanation of why.
Classes that implement IDisposable are best used within the confines of a using statement that will take care of disposing it for you.
The clear exception to this is when multiple calls to the disposable class will be needed in the context of a single business action -- and that action is too spread out to be wrapped in a using statement. In this case, wrapping all the calls into a second disposable class that has the first as a private member. when the second class is disposed it should dispose of any private members that are disposable.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
Interviewer asked me this question:
You have implemented the singleton Pattern and it is used by 3
classes, one class disposed the object. Does other two classes still
able to access?
how does that work?
could you please explain?
If it's a Singleton, then that means there is only one instance of it - everyone who references it gets the same instance. If you were to dispose the instance - though that seems pretty odd as a concept for a Singleton - then the classes that then try to reference it would likely get an ObjectDisposedException
Singleton Pattern and it is used by 3 classes
I am assuming they meant 3 variables/references, not classes.
Example:
var a = MyClass.Instance;
var b = MyClass.Instance;
var c = MyClass.Instance;
one class disposed the object - does other two classes still able to
access?
No
how it will work? could you please explain?
The purpose of the singelton pattern is to only have one instance of the class. So, whenever it is referenced i.e., (a, b, c) above, it is the same instance (it's pointing to the same address in memory).
So, if one of the classes disposed of the instance, this will mean that all references that currently point to the singleton will also have the disposed object as well (since all references were pointing to the same address location where the object lived).
Example:
a.Dispose(); // will dispose MyClass.Instance, making all references to it also have the disposed object
// a will now be disposed
// b will now be disposed
// c will now be disposed
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
I recently asked a question about StackOverflowExeptions and the explanations were very helpful!
However, I wrote a method and tried to figure out where T cached is allocated (heap/stack):
private Dictionary<Type, Component> _cachedComponents = new Dictionary<Type, Component>();
public T GetCachedComponent<T>() where T : Component {
//Not yet sure if the next line works or throws an exception -> just ignore it
if(_cachedComponents[typeof(T)] != null) {
return (T)_cachedComponents[typeof(T)]
} else {
T cached = this.GetComponent<T>();
_cachedComponents.Add(typeof(T), cached);
return cached;
}
}
Since T cached is declared inside the method I assume it is allocated on the stack, right?
But the reference is then added to the dictionary, wich should be allocated on the heap, right?
The stack is "cleared" after the method returns, right?
But what happens to T cached? Is it going to be moved to the heap? (Because the stack does not "carry the data" anymore but the dictionary still holds a reference)
Since T cached is declared inside the method I assume it is allocated
on the stack, right?
T being allocated in a method doesn't effect it being on the heap or the stack. The decision whether it is the former or the latter is based on whether this is a reference type or a value type.
But the reference is then added to the dictionary, wich should be
allocated on the heap, right?
Once the reference is added to the Dictionary<TKey, TValue>, the key will be stored inside the dictionary, which is allocated on the heap, as it is a reference type.
The stack is "cleared" after the method returns, right?
The stack frame is cleared once the method returns.
But what happens to T cached? Is it going to be moved to the heap?
If T is cached inside the dictionary, then it is already allocated on the heap.
Overall, I assume you ask these questions as for general knowledge. You shouldn't be worrying about this too much, as what I wrote here is an implementation detail and is subject to change.