I am using ClrMd to examine memory in a C# app and successively created a runtime object on a process.
I use the runtime object to call EnumerateObjects(). This returns a collection of ulongs that are references to all the objects on the heap. If the reference is to a string, I have no problem reconstituting the string using the ClrType GetValue(). However, when I call GetValue() on a reference to other objects, GetValue returns what appears to be another reference (i.e. ulong).
Do I need to execute some kind of C# unsafe code?
By the way, I get the same result with EnumerateObjectAddresses() (is there a difference between the two?)
Related
I am trying to understand the concept of why struct vs. class have difference results. Why is the result the same here but different on structs:
import UIKit
class Message {
var internalText: String = "This is some text"
}
// create new instance
var firstMessage = Message()
//if I assign, its a reference to the original instance
var secondMessage = firstMessage
secondMessage.internalText += " with some more text added on."
//print both
print(firstMessage.internalText)
print(secondMessage.internalText)
output:
This is some text with some more text added on.
This is some text with some more text added on.
Now if you change the above from declaration from "class" to "struct"
struct Message {
var internalText: String = "This is some text"
}
...
output becomes:
This is some text
This is some text with some more text added on.
Why in the class declaration does it change the firstMessage object. Are they the same objects? Is this a rule that if I assign a new object from the old object? Then I would have to declare secondMessage = Message() to make it a new instance.
Thanks in advance.
In Swift, classes are reference types, whereas structs are value types. Value types are copied on variable assignment, whereas reference types are not.
More explanation
The system stores instantiated classes and structs into the memory. There are two main sections of the memory involved in the storage of data, the stack, and the heap. The stack contains the local variables introduced in the current method or function, and the heap is used as a kinda external memory, storing larger values. The program can only access variables stored in the stack, so a reference to the value in the heap should be held in the stack.
When you instantiate a class object by using something like Message(), a free space is reserved in your memory's heap and a reference to it is held in the stack. When you assign the same variable to a new one, the reference is copied and both variables will refer to the same bytes in the heap, so changing one changes another too.
When using structs, all the space is being reserved on the stack and there is no such thing as a pointer or reference, so when assigning to a new variable, all the data gets copied (in fact, the system is smart enough to only copy the necessary values which are being changed).
You can see a nice tutorial covering these subjects here.
Why in the class declaration does it change the firstMessage object. Are they the same objects?
The example you gave is a really nice one because it succinctly illustrates the difference between class and struct, and you came about this close -> <- to answering your own question, even if you didn't realize it. As the other answers have explained, class creates a reference type, which means that when you assign an instance of a class to a variable, that variable gets a reference to the object, not a copy of it. You said so yourself:
//if I assign, its a reference to the original instance
var secondMessage = firstMessage
In your example, firstMessage and secondMessage are really references to the one object that you created. This kind of thing is done all the time in object oriented languages because it's often important to know that you're dealing with a specific object and not a copy, especially if you might want to make changes to that object. But that also brings danger: if your code can get a reference to an object and change it, so can some other code in the program. Shared objects that can be changed create all kinds of headaches when you start writing multithreaded code. When you added text to secondMessage, firstMessage also changed because both variables refer to the same object.
Changing the declaration of Message to struct makes it a value type, where assignment (for example) creates a new copy of the object in question instead of a new reference to the same object. When you added text to secondMessage after changing Message to a struct, the assignment secondMessage = firstMessage created a copy of firstMessage, and you only changed that copy.
Is this a rule that if I assign a new object from the old object?
Whether your assignment creates a copy of the object or a reference to it depends, as you've shown, on whether the thing being assigned has reference semantics (class) or value semantics (struct). So you need to be aware of the difference, but most of the time you don't need to think too hard about it. If you're dealing with an object where you don't care about the object's identity and are mainly concerned with its contents (like a number, string, or array), expect that to be a struct. If you care about which object you're dealing with, like the front window or the current document, that'll be a class.
Then I would have to declare secondMessage = Message() to make it a new instance.
Right -- if Message is a class, assigning one to a new variable or passing it into a method won't create a new one. So again, are you more likely to care about which message you're dealing with, or what is in the message?
Simple answer: Classes are reference types Structs are value types.
In the class, firstMessage is set to Message() which is an instance of the whole class Message. So when secondMessage gets set to equal firstMessage, secondMessage Doesn’t make a new class again, it just makes a note of where firstMessage is at and they both can now operate it. But because they both in the same location, the internalText will be the same for both.
While with the struct, since they are value types, secondMessage copies all the values from firstMessage and creates its own independent object of type Message.
Classes are reference types, meaning that the firstMessage and secondMessage variables you defined in your first snippet stores only a reference to the class instance you created. Imagine your object is located somewhere in your memory heap with an id (for example, id0001), then both firstMessage and secondMessage stores only the id, which is id0001, so they both refer to the same object in memory.
On the other hand, structs are value types, meaning that the struct variables store unique objects directly; unlike reference types, no sharing is going on. So when you are assigning a new struct variable to a previous struct variable, the object gets copied, and the two variables store two unique objects with different memory addresses (IDs).
For more information, check out the official doc on classes and structs.
Let us understand the same concept with an example,
Suppose you have a google sheet in which you are adding some text and at a time you share that sheet to some other person for editing or deleting purpose. So when the other person do any changes you can see at a time. This concept is followed in class.
Moreover, classes are reference types because here you are passing a reference(sheet).
However, you have downloaded that google sheet and send its copy to another person so at that time you are not able to see the changes until and unless the person sends back the sheet. And this is the same concept followed in struct. A struct is value type because we are passing a copy(downloaded sheet).
We can inherit class but cannot inherit struct
Think of structs as a Microsoft Excel file. You create a copy and send it to me. When I change my copy, your copy doesn't get changed.
Classes on the other hand are more like Google Sheets. When I make changes to the file you shared with me, you can see the changes.
Instances of structs make copies and have different places in memory
Instances of classes point to the same place in memory
I need to control destruction of a value-class object in Matlab.
The problem is as following.
I have a some program (let's call it MyProg) that during execution creates a value-class object (lets call it MyValClass). MyValClass has a handle-class object as one of its properties (lets call it MyHandClass). That handle class initiates some events that MyProg listens to.
The problem appears is MyValClass object is destroyed (usually it happens on exceptions or user termination). I guess, that because there are still listeners listening to events of MyHandClass, the MyHandClass object is not destroyed, and remains in memory.
I would like to control the destruction of MyValClass object, so that I could implicitly delete its MyHandClass property. Is it possible?
Here is a bit of background on handle vs value classes:
Objects of a value class are not "destroyed", and they do not have a destructor method. Think of value classes as behaving like the variable a when you've set a = 1. a is not "destroyed" when you type clear a, there's just no variable a any more. Value objects are just data, like 1, and they don't get destroyed.
The above is true even if the value class has a method called delete. A delete method on a value class is just like any other method. It is not a destructor, and it does not get automatically called when the variable is cleared. It only gets called when you explicitly call it.
Handle classes always, whether you implement one or not, have a method called delete, which is a destructor method (i.e. is called when the object is destroyed). If you don't implement one, they will be given a default method called delete, which does nothing other than destroy the object. If you implement a delete method, MATLAB will run that when destroying the object. But there is always a delete method that is a destructor, even if you don't implement one.
So - to your question - if you wish to control the destruction of MyValClass, you must change it to become a handle class. If it's a value class, it is not destroyed and there's nothing to control.
There are other things you might be able to do instead of directly "controlling the destruction". For example, you create an onCleanup object. This is a class that does nothing but execute a user-specified function on its destruction (it's a handle class, so it can do this). So if your code exits because of an exception or user termination, the onCleanup destructor will execute. You could, for example, put some code in there that would explicitly find references to MyHandlClass and deleted them.
Hope that helps!
The destructor for value object may be necessary, for example, if the class is responsible for accessing data from file and you want to close file when your accessor goes out of scope. There are number of reasons why you would not want such class to be a handle class (e.g. weird behavior on array of objects)
Other reason is creating existing objects counter.
My solution is to define hidden property, delete_, and assign onCleanup(#()something) object to this property. The function, provided to onCleanup would close the files, decrement object counter etc....
I've been having some issues with conditional binding returning an invalid (but non-nil) object from the watch accelerometer. I was thinking maybe making a copy of the object could help the problem, but I wasn't sure if that was already occurring. If I use code such as:
if let data = recorder.accelerometerData(from: startDate, to: endDate){...}
is this already creating a copy of the CMSensorDataList object or am I simply getting a reference to it?
It just depends upon whether the type wrapped by the optional was a value type or reference type. If reference type, it's obviously pass by reference. If value type, it's copied (unless CoW, copy-on-write, in which case it's copied if and when it's mutated).
In this case, CMSensorDataList is a class, so it's a reference to that instance, not a copy of it.
Function in NP API plugin creates NPObject and returns into javascript. Then javascript variable with returned NPObject is used as parameter for some other function of plugin. e.g.
var obj = plugin.GetObject()
plugin.UseObject( obj )
But in second function (UseObject) value of parameter is not original NPObject but NPObject JS wrapper class.
Is there way to get original NPObject from instance of NPObject JS wrapper class?
Short answer: you can't.
More involved answer: Some browsers will give you the originating object, but most these days won't, and there is no way to dereference past their opaque NPObject interface to get back to the underlying object.
Alternate solution: Instead of trying to get it that way, add a unique id to your NPObject and a global map to the pointer. Then when you get an NPObject that you think might be the object, call a method (or get a property) to get the unique ID and then you can look up the pointer.
this is the only method that I've found that works consistently across all browsers.
Related question:
Scala closures compared to Java innerclasses -> final VS var
I wonder when do Scala makes the variables captured into a closure live on the heap instead of the stack. I'm reading the Scala book of Martin Odersky but for now i didn't find this information. Can someone explain what's behind the hood?
An anonymous function (and actually, any function) in scala is actually an object (an instance of Function*). When it is instantiated, the capture of vals is done by copying the vals into internal fields of the function object. In the function body (that is, in the function object's apply method) the access to the captured vals is done by accessing these fields.
The capture of vars is similar, except that the compiler has to add a level of indirection: the var value is accessed through some hidden mutable holder (simply an object with a mutable field pointing to the current value of the var) and this is this holder that is copied into the function object. When writing into the var (either by local code or by the function object), it is the holder's field which is written. This mechanism ensures that the local code and function's code manipulate the same data, and both see each other's modifications.
So the answer is that a captured vals and a captured var both always live on the heap (whether directly as a field of the function object, or as a field of some wrapper object)
I don't know the insides of the compiler, but here is how it can be done. For each local variable, the compiler maintains a flag initialized to false. Whenever the variable is used, the compiler checks whether it is being used inside a class or closure that doesn't contain the variable's declaration; if so the flag is set to true. At the end of the variable's scope, if the flag is still false, the variable can live on the stack. Otherwise it must live on the heap.