Explain the difference between mutable and immutable - iphone

What is the difference between mutable and immutable?
Such as:
NSString vs NSMutableString.
NSArray vs NSMutableArray.
NSDictionary vs NSMutableDictionary.
What is the difference between a mutable object and the other object [which I assume is immutable]?

A mutable object can be mutated or changed. An immutable object cannot. For example, while you can add or remove objects from an NSMutableArray, you cannot do either with an NSArray.
Mutable objects can have elements changed, added to, or removed, which cannot be achieved with immutable objects. Immutable objects are stuck with whatever input you gave them in their [[object alloc] initWith...] initializer.
The advantages of your mutable objects is obvious, but they should only be used when necessary (which is a lot less often than you think) as they take up more memory than immutable objects.

The basic difference is:
NSStrings cannot be edited, only reassigned. This means when the value of an NSString changes, it is actually pointing to a new location in memory.
NSMutableString objects can be edited and maintain the same pointer.
A common practical difference is:
If you create 1 NSString and then assign another one to it, then edit either one of them, they will now be pointing to different strings.
If you do the same thing with NSMutableStrings, but then just edit one of them (not reassign it), they will both be pointing to the newly edited object.

Mutable objects can be modified, immutable objects can't.
Eg:
NSMutableArray has addObject: removeObject: methods (and more), but NSArray doesn't.
Modifying strings:
NSString *myString = #"hello";
myString = [myString stringByAppendingString:#" world"];
vs
NSMutableString *myString = #"hello";
[myString appendString:#" world"];
Mutable objects are particularly useful when dealing with arrays,
Eg if you have an NSArray of NSMutableStrings you can do:
[myArray makeObjectsPerformSelector:#selector(appendString:) withObject:#"!!!"];
which will add 3 ! to the end of each string in the array.
But if you have an NSArray of NSStrings (therefore immutable), you can't do this (at least it's a lot harder, and more code, than using NSMutableString)

A mutable object can be mutated or changed. An immutable object cannot. For example, while you can add or remove objects from an NSMutableArray, you cannot do either with an NSArray.

The english definition of "mutable" is really all you need here. Mutable objects can be modified after creation. Immutable objects cannot be modified after creation. That applies to all of the classes you listed.
Practically speaking, all of the mutable classes are subclasses of the immutable ones, and each adds its own interface to allow programmatic modification of the object, like addObject:, setObject:forKey:, etc...

Everyone says you can't change/modify an immutable object. I have a different way of explaining. You can modify it, but then you would be creating a new pointer to the new object, its not like you modified the old object, its a brand. New. Object. Any pointer that had a previously pointing pointer to it, would not see its change. However if its a Mutable Object, any previously pointing object to it would be seeing its new value. See the examples.
FYI %p prints the pointer location in heap.
NSString * A = #"Bob";
NSString * B = #"Bob";
NSString * C = #"Bob1";
NSString * D = A;
NSLog(#"\n %p for A \n %p for B \n %p for C \n %p for D",A,B,C,D);
// memory location of A,B,D are same.
0x104129068 for A
0x104129068 for B
0x104129088 for C
0x104129068 for D
Modifying pointer A's object
A = #"Bob2"; // this would create a new memory location for A, its previous memory location is still retained by B
NSLog(#"\n%p for A \n%p for B \n%p for C \n %p for D",A,B,C, D);
// A has a **new** memory location, B,D have same memory location.
0x1041290c8 for A
0x104129068 for B
0x104129088 for C
0x104129068
for D
// NSMutableString * AA = #"Bob"; <-- you CAN'T do this you will get error: Incompatible pointer types initializing NSMutableString with an Expression of type NSString
NSMutableString * AA = [NSMutableString stringWithString:#"Bob1"];
NSString * BB = #"Bob";
NSString * CC = #"Bob1";
NSString * DD = AA;
NSLog(#"\n %p for AA \n %p for BB \n %p for CC \n %p for DD",AA,BB,CC,DD);
// memory location of AA,DD are same.
0x7ff26af14490 for AA
0x104129068 for BB
0x104129088 for CC
0x7ff26af14490 for DD
Modifying pointer AA's object
AA = (NSMutableString*)#"Bob3"; // This would NOT create a new memory location for A since its Mutable-- D was and still pointing to some location
NSLog(#"\n%p for AA \n%p for BB \n%p for CC \n %p for D",AA,BB,CC,DD);
// memory location of AA,DD are NOT same.
0x104129128 for AA
0x104129068 for BB
0x104129088 for CC
0x7ff26af14490 for DD
As you would imagine, the default storage attribute for all NSString properties is retain. For more information on copy & retain I highly suggest you read this question.NSString property: copy or retain?

Mutable can be changed, immutable cannot.
When you share a mutable objects, you should expected the some one can change it.
When you share an immutable object, you expected the no one will changed.

There are some other difference which are interesting a immutable object when copied will instead be retained. There may also be lots of under the hood differences that apple implements for performance reason depend on whether a object is mutable or not, for example, do the substring methods copy the actual bytes of their parent string or do the just point a subrange of the parent string if it is immutable, probable not but who knows.

Immutability as: “not capable of or susceptible to change” and mutability as “capable of change or of being changed”.
To rephrase immutable means can’t be changed and mutable means can be changed.
In swift code, we apply the concepts of immutability and mutability using the keywords let and var respectively.
for more detail visit this link it has detail description with code
Mutable variables
// Declaration and assignment of a mutable variable name.
var name = "Kory"
// Reassignment or mutation of the variable name.
name = "Ryan"
Above we declared a variable named “name” and assigned its value to be the String literal “Kory”. On line five we reassigned the variable to be the String literal “Ryan”.
This is an example of a mutable variable. Using the keyword var allows us to change the value the variable holds. The variable “name” can be changed to whatever String we like.
Mutable variables are needed when the value of a variable is expected to change. Let’s take a look at a slightly more complicated example.
// Declares a new type Person
struct Person {
var name: String
var age: Int
}
// Creates an instance of person named kory.
var kory = Person(name: "Kory", age: 30)
// Mutates Kory's properties
kory.age = 31
kory.name = "Scooby"
In the above example both the name and age properties of instance of a Person are mutable, they can be changed. In this example mutability is important. A person’s name or age can and will change in real life. Having mutable variables allows our data too closely resemble the real world thing we are trying to model.
Immutable contants
Often the words variable and constants are used interchangeably but there is a subtle difference. Mutability. Variables as the name implies can vary with the data they hold. Constants cannot and are therefore are immutable and in other words constant. Swift allows us to represent an immutable constant with the keyword “let”. Consider the below example.
// Declaration and assignment of a mutable variable name.
let name = "Kory"
name = "Ryan" // Cannot assign to property: 'name' is a 'let' constant
The above example is nearly identical to the mutable example but will not compile. When an identifier such as “name” is set to be immutable with the keyword “let” it cannot be changed once assigned. You can delay assignment as illustrated below. But you cannot change name once it has been assigned.
let name: String
// Some important code here
name = "Kory"
You can also use constants inside of structs and classes when you want to make one or more properties immutable even if the instance is declared as mutable.
// Declares a new type Person with constants properties
struct Person {
age name: String
let age: Int
}
var kory = Person(name: "Kory", age: 30)
kory.name = "Ryan"
kory.age = 30 // Cannot assign to property: 'age' is a 'let' constant
Even though kory is declared with var, internally age is declared with let and cannot be mutated. Mutating name is fine.

Related

Why does the Swift identity operator "===" return true for NSNumbers?

the operator "===" should compare class references to determine if both sides are referring same object:
var objectA : NSNumber = 1
var objectB : NSNumber = 1
print(objectA === objectB)
// return true,
so my question is NSNumber wrapped the object into the same object, how is the back-end logic of doing so.
NSNumber is one of a small handful of classes which can sometimes be represented as tagged pointers (at least on Apple platforms; I don't think this applies to the open-source version of (Core)Foundation).
Basically, this means that rather than a pointer to an actual instance of a class located elsewhere in memory, the NSNumber stores its value (in this case 1) directly inside the pointer. You can see this for yourself:
import Foundation
let x: NSNumber = 1
let y: NSNumber = 2
// Tagged pointers: the number is stored inside the pointer representation.
print(Unmanaged.passUnretained(x).toOpaque()) // 0x0000000000000137
print(Unmanaged.passUnretained(y).toOpaque()) // 0x0000000000000237
class C {}
let c = C()
// Not a tagged pointer; just a regular pointer to allocated memory.
print(Unmanaged.passUnretained(c).toOpaque()) // 0x00007fb32276daa0
The same optimizations can apply to NSString and other types too. For more details, read Mike Ash's excellent in-depth blog posts:
Friday Q&A 2012-07-27: Let's Build Tagged Pointers
Friday Q&A 2015-07-31: Tagged Pointer Strings
Don't rely on this, however. It's just an implementation detail, and not all NSNumbers may be represented this way. The correct way to compare them for equality is ==.

Swift's memory management

I'm a little confused regarding Swift's memory management. Can someone explain to me how come kid1 always stays at the same memory address? Even when I do kid1=kid2 or initialize a new object?
Your code prints the memory location of the kid1 variable,
and that does not change if you assign a new value to the variable.
If Kid is a reference type (class) then you can use
ObjectIdentifier to get a unique identifier for the class instance
that the variable references:
var kid1 = Kid(name: "A")
var kid2 = Kid(name: "B")
print(ObjectIdentifier(kid1)) // ObjectIdentifier(0x0000000100b06220)
print(ObjectIdentifier(kid2)) // ObjectIdentifier(0x0000000100b06250)
kid1 = kid2
print(ObjectIdentifier(kid1)) // ObjectIdentifier(0x0000000100b06250)
The object identifier happens to be the address of the pointed-to
instance, but that is an undocumented implementation detail.
If you need to convert an object reference to a real pointer
then you can do (compare How to cast self to UnsafeMutablePointer<Void> type in swift)
print(Unmanaged.passUnretained(kid1).toOpaque())
Why kid1 is pointing to the same MemoryAddress each time?
In general, a class is a reference type. Which means, all instances of a class will share a single copy of data.
I.e, it's like a mutable data, if you change a data at any once instance of class, then it will affect that change to all its dependent instances.
It mainly deals with the memory addresses.
I think you have declared your class like below:
class Kid {
var name: String?
init(name:String) {
self.name = name
}
}
then for
var kid1 = Kid(name: "A"): For kid1 instance it will assign some memory address, say <Kid: 0x60400024b400>
var kid2 = Kid(name: "B"): For kid2 instance it will assign some other memory address, say <Kid: 0x60400024b760>
when you do kid1 =kid2: kid1 memory address will get changed to kid2 memory address. So, kid1 and kid2 will pointing to same memory address.
kid1.name = "C": now if a change kid1.name,..it will reflect to kid2.name value also,because both are pointing to same memory address.
Therefore you get:
kid1.name == "C"
kid2.name == "C"
There are 2 categories that are supported by Swift (Value Types, Reference Type). We have 3 different behaviours that we can have for those types - Copy by reference, Copy by value and Copy-on-Write. Classes as in your case are using copy by reference which means both instances point to same address - share a single copy of data. More details are described in my post about swift memory management and performance, I go as deep as binary values in the memory. I hope it helps:
Swift Memory Management and Performance

is NSString value cannot be changed once it is provided a value?

Hi I got an information that NSString value is immutable and cannot be changed once it is provided a value.
But I have created and tested the following code:
NSString *str=[[NSString alloc] initWithString:#"Hello"];
NSLog(#"\n\nstr = %#",str);
str=#"asdasd";
NSLog(#"\n\n new str = %#",str);
and this gives "Hello" as first str value and "asdasd" as second str value. If it is so what is the relevance of calling NSString immutable?Thanks in advance.
What you're doing on the third line is just creating a new string and pointing it with the str variable. You didn't change the original string, but rather made the variable point to a new one.
NSString is immutable. You cannot mutate it. Your confusion arises from the fact that your variable (pointer) is not const.
All you're doing is reassigning the pointer to a different immutable string.
If you were to attempt to append a string to either, then an error would ensue. This, specifically, is "…the relevance of calling NSString immutable". You should interpret this as the string instance may not be mutated, even though the variable you have declared may be assigned another NSString instance because it is not const.
You can make both the pointer const and the string immutable like so:
NSString * const aStr = #"aStr";
You're confusing an immutable object and a constant pointer (plus you're leaking memory). Here you don't really change the NSString instance (that is, the object itself), but just a pointer to it. The point is that you can assign different instances of an NSString to the same variable, it won't change the internal contents of the object, nor would it make it respond to NSMutableString's mutation messages such as appendString etc.
Use this will sol your problem...
NSString *str=[NSString stringWithFormat:#"Hello"];
NSLog(#"\n\nstr = %#",str);
str = nil;
str=#"asdasd";
NSLog(#"\n\n new str = %#",str);
This some basic that you should know..
NSString *s1 = #"string1";
NSString *s2 = [[NSString alloc] initWithString:#"string2"];
NSString *s3 = [NSString stringWithFormat:#"string3"];
s1 in this case is a pointer to a constant string. s2 and s3 both point to new strings that you've created, but s2 has been retained for you, and s3 has been autoreleased. If you just need a temporary object, the autoreleased object s3 or the constant object s1 are good choices. If you need to keep the string around, you should use s2 (actually now that I think about it s1 will work in this case too - it's not really idiomatic, though).
You can make s1 or s3 equivalent to s2 by sending them a retain message. You could also turn s2 into an equivalent object by sending it an autorelease message.

What kind of data is in an "enum" type constant? How to add it to an NSArray?

What kind of information is stored behind such an enum type thing? Example:
typedef enum {
UIViewAnimationCurveEaseInOut,
UIViewAnimationCurveEaseIn,
UIViewAnimationCurveEaseOut,
UIViewAnimationCurveLinear
} UIViewAnimationCurve;
I am not sure if I can safely add such an enum constant to an array. Any idea?
Enums in Objective-C are exactly the same as those in C. Each item in your enum is automatically given an integer value, by default starting with zero.
For the example you provided: UIViewAnimationCurveEaseInOut would be 0; UIViewAnimationCurveEaseIn would be 1, and so on.
You can specify the value for the enum if required:
typedef enum {
UIViewAnimationCurveEaseInOut,
UIViewAnimationCurveEaseIn = 0,
UIViewAnimationCurveEaseOut,
UIViewAnimationCurveLinear
} UIViewAnimationCurve;
This result of this would be: UIViewAnimationCurveEaseInOut is 0; UIViewAnimationCurveEaseIn is 0; UIViewAnimationCurveEaseOut is 1; and so on. However, for basic purposes you shouldn't need to do anything like that; it just gives you some useful info to toy with.
It should be noted based on the above, that an enum can't assume to be a unique value; different enum identifiers can be equal in value to each other.
Adding an enum item to a NSArray is as simple as adding an integer. The only difference would be that you use the enum identifer instead.
[myArray addObject:[NSNumber numberWithInt:UIViewAnimationCurveEaseInOut]];
You can check this out for yourself by simply outputting each enum to the console and checking the value it provides you with. This gives you the opportunity to investigate the details of how it operates. But for the most part you won't really need to know on a day to day basis.
Enums are typically int values. You can store them in an array by wrapping them in an NSNumber:
[myMutableArray addObject:[NSNumber numberWithInt:myAnimationCurve]];
... then get them back out like this:
UIViewAnimationCurve myAnimationCurve = [[myMutableArray lastObject] intValue];
Enums in Objective-C are the same as enums in vanilla C. It's just an int. If you're using an NSArray, then it expects a pointer and you'll get a warning if you try to add an int to it:
NSMutableArray *myArray = [[NSMutableArray alloc] init];
[myArray addObject:UIViewAnimationCurveEaseInOut];
// Last line results in:
// warning: passing argument 1 of 'addObject:' makes
// pointer from integer without a cast
If you're storing a large collection of 32-bit integers, consider using the appropriate CF collection type rather than the NS collection type. These allow you to pass in custom retain methods, which gets rid of the need to box every integer added to the collection.
For example, let's say you want a straight array of 32-bit ints. Use:
CFMutableArrayRef arrayRef = CFArrayCreateMutable(kCFAllocatorDefault, 0, NULL);
The last parameter tells the array to not retain/release the "addresses" you pass in to it. So when you do something like this:
CFArrayAppendValue(arrayRef, 1);
What the array thinks is that you're passing in a pointer to an object living at the memory address 0x1. But since you told it to not call retain/release on that pointer, it gets treated as a standard int by the collection.
FWIW, for educational value, standard NSMutableArrays have equivalent CF types. Through toll-free bridging you can use the CF collection as a standard Foundation collection:
CFMutableArrayRef arrayRef = CFArrayCreateMutable(kCFAllocatorDefault, 0, kCFTypeArrayCallbacks);
NSMutableArray *array = (NSMutableArray *)arrayRef;
[array addObject:#"hi there!"];
NSLog(#"%#", [array objectAtIndex:0]); // prints "hi there!"
You can apply the same tricks to dictionaries (with CFDictionary/CFMutableDictionary), sets (CFSet/CFMutableSet), etc.

Obj-C: Difference between "Fairfield" and #"Fairfield" (with at string)?

I just had a ridonkulous typo in my iPhone app, answered here.
Now I'm wondering about the #"..." notation.
why this works:
NSArray *someArray = [NSArray arrayWithObjects: #"Fairfield", nil];
and this does not (even though it compiles, it will throw an EXC_BAD_ACCESS):
NSArray *someArray = [NSArray arrayWithObjects: "#Fairfield", nil];
Edit:
Ok, so you guys have pointed out that I can't add a C string to an NSArray, because it's obviously not an object.
Now another question: Isn't this somewhat of an oversight? I mean, why does the "...WithObjects:" message specify a list of (id) instead of (NSObject *)?
"#Fairfield" is a normal C string with an '#' character in it. #"Fairfield" is an Objective-C string (NSString on OS X) with no literal '#' in it.
You cannot add C strings to Cocoa collections.
It accepts id rather than NSObject because all initialisers return id. All initialisers return id because subclasses would otherwise override the return type of their ancestors' initialisers.
For example, -[NSMutableString init] can't return NSMutableString * because it subclasses -[NSString init], which can't return NSString * because it overrides -[NSObject init].
Unfortunately, implicit type-casting between const char * and id is perfectly legit, so the compiler won't throw a warning, however a static analyser may be able to pick this sort of mishap up fairly easily.
"Fairfield" is a C string, #"Fairfield" is an Objective-C string.
#"Fairfield" is an object (NSString), so you can send it methods ([#"Fairfield" uppercaseString]) and add it to Objective-C arrays ([NSArray arrayWithObjects:#"Fairfield",nil]). You can only add objects to NSArrays.
On the other hand, "Fairfield" is a C string, and is generally not used in Cocoa. For the most part, you can get by with only using #"Fairfield"
The other reason that a number of things in Cocoa deal with id rather than NSObject* is because, unlike some other languages (say, Java and C#), where all objects in the language must inherit from some global base class, it's entirely possible to have objects that do not descend from NSObject (NSProxy being one example). It's not something you'd do often, but it is possible. The id type means "pointer to any Objective C instance".