Please enable JavaScript.
Coggle requires JavaScript to display documents.
Mutability-immutability-reference-value types (Reference vs value types…
Mutability-immutability-reference-value types
Heap & Stack
Value types are not always at stack
Local variables yes
If properties of reference type no
Visualization of stack and heap
Why not use stack for everything since it is fast?
Explain
Should the programmer care?
It is just an abstraction
Most languages do not give option or expose
Definitions
the heap can be pictured as a random jumble of objects. Its advantage is that it allows objects to be allocated or deallocated in a random order. As we’ll see later, the heap requires the overhead of a memory manager and garbage collector to keep things in order.
The stack is a simple first-in last-out memory structure, and is highly efficient. When a method is invoked, the CLR bookmarks the top of the stack. The method then pushes data onto the stack as it executes. When the method completes, the CLR just resets the stack to its previous bookmark—“popping” all the method’s memory allocations is one simple operation!
What is saved where
The stack is always used to store the following two things:
The reference portion of reference-typed local variables and parameters (such as the myTextBox reference)
Value-typed local variables and method parameters (structs, as well as integers, bools, chars, DateTimes, etc.)
The following data is stored on the heap:
The content of reference-type objects.
Anything structured inside a reference-type object.
Reference vs value types
Value types contain their values
A single space is allocated in memory
On stack or heap
References contain pointer to location of values
Two spaces are allocated in memory
One for the data one for the pointer
Pointer on stack or heap, data on heap
Identity/equality notion
Copying behavior of value types
Efficiency COW of swift struct
Saved on stack or heap
Check C++
Programmer to determine where it is saved
References introduce lifecycle management
Values managed through scope
When do the copy semantics appear?
When we assign to another local variable
When we pass to a method
Is there any language where method does not copy by value?
By value
C#
Supports by reference by ref keyword
Java
Only by value
Swift
default is copy by value supports copy by reference
Actually the optimized behavior of inout is call by reference
copy-in copy-out or call by value result. For example, when a computed property or a property with observers is passed as an in-out parameter, its getter is called as part of the function call and its setter is called as part of the function return.
As an optimization, when the argument is a value stored at a physical address in memory, the same memory location is used both inside and outside the function body. The optimized behavior is known as call by reference;
Scala
Default is by value
Supports by name
Lazy evaluation of the argument when it needs to be used
Think about passing an expression as an argument
Closures?
Immutability / mutability
Is it related to value/reference types?
both can be immutable/mutable
Var vs let declarations
Reference vs value types
in general does not give much info
could be a val and the object might contain mutable property(either value or reference types)
could be var declaration and the object might be immutable
if it is a struct with value type properties and these are let (and do not contain any reference type properties) it will be immutable
maybe in structs and if all properties are structs and so on it tells something
It is just in the declaration variable level if it can change or not. That's all. No more guarantees
Dangerous when var property accessed thorugh a reference
even if the property type is immutable, the outside object is mutable, with a mutable property
ii might change underneath it's nose
no copying or something
Prefer immutability but essentially need to handle mutation
Copying!
But at some point something will need to keep the change in our system
Observables?
IOREF?
See issue with our view ideals and arrays
Value type but accessed through reference
Copying no longer can save us
Swift’s structs vs data classes of Scala and kotlin
They try to simulate value types
behavior
but essentially are references
equality notion of value types(not reference equality)
copying
What do structs offer more?
a let declaration on a struct means more
Need to check properties here as well
A val on a data class means only the reference can’t change
Need to check the properties and so on
The mutating keyword adds some extra safety?
also the semantics are clear
the equality is value equality (the only available)
the purpose is obviously of a value class
Resources
https://www.tutorialsteacher.com/csharp/csharp-value-type-and-reference-type
Ray wenderlich post
http://tooslowexception.com/heap-vs-stack-value-type-vs-reference-type/
http://www.albahari.com/valuevsreftypes.aspx
really good
Other interesting topics
Scala in-line classes and kotlin