When I receive an NSNotification do I ever need to cast notification.object? Suppose I know notification.object will be an instance of MyClass and I do the following:
MyClass *myClass = notification.object;
Is any casting necessary here? How is the above assignment different from:
MyClass *myClass = (MyClass *)notification.object;
No, it is entirely unneccessary and does not change anything about the behavior of your program. Casting only happens at compile time, and in the case of pointers, is just used to assure the compiler that you know what type the object is.
The compiler may complain about an assignment if you are, for example, setting a variable of type Subclass to the result of a method that returns type Superclass, where you know that the actual object you are going to get back is of type Subclass. In that case, you would cast to the subclass. E.g.,
MyViewController * vc = (MyViewController *)[someWindow rootViewController];
The type of notification.object is id, a generic object pointer, and the compiler is perfectly happy to assign such a pointer to any other type of pointer.
No. Objective-C doesn't require a cast from type id to another object type.
Related
I know that in C casting one variable to another type tells the compiler to act as if that variable is of that type and size in memory.
Example:
int* a = (char*)b;
Take the value of b (which is a 1 byte memory address) and store that in the 4 byte variable a. (Correct me if i'm wrong)
How does this work which casting an Objective-C object?
I also understand that each object is just a C struct holding a pointer to its class, instance variable list, etc.
If I have a class which is a subclass of UIView called MyView and I am passed a pointer to a UIView, maybe a method argument, and I do this:
-(id)setupThisViewForMe:(UIView*)aView {
MyView* newView = (MyView*)aView;
newView = [[MyView alloc]initWithFrame:CGRectMake(0.0f,0.0f,100.0f,100.0f)];
[newView takeOverTheWorldWithMyMethodInSubclass];
return newView;
}
What exactly is the compiler doing at compile time?
What exactly is the compiler doing at compile time [when you cast Objective C objects]?
Almost nothing: the compiler performs checks related to ARC, making sure that you are not coercing a weak pointer into a strong variable or vice versa, but other than that, the compiler trusts you to do the right thing. Of course if you "lie" to your compiler, it will "pay back" with unsupported message exceptions at runtime.
In some sample code, an NSNumber is added to a mutable array:
// In the .h, as an instance variable:
NSMutableArray *sequence;
// In the .m file:
sequence = [[NSMutableArray alloc] initWithCapacity:100];
[sequence addObject:[NSNumber numberWithInt:123]];
Then later on, when the integer is needed, it uses:
[(NSNumber *)[sequence objectAtIndex:aCounter] intValue]
I just wonder why the cast (NSNumber *) is needed? Because the program runs fine without it, too. Is it just a good practice? If so, what can it prevent from happening? If there is a bug so that one element is not an NSNumber *, then casting it can create strange behavior too.
Casting only makes the compiler believe that the object (which is returned as of type id, i. e. generic object type with no other information!) is actually an NSNumber, so that it can identify correclty its intValue etc. methods. It doesn't make things differ at runtime. If the object is not an NSNumber, then it will crash at runtime, with or without the casting.
It is fine to do it without the casting, the casting just makes it explicit that you treat it as an NSNumber, if you have a bug and this is not an NSNumber (or more precisly, don't respond to intValue) you'll get some odd behavior anyway.
//In objective-C any object can send message to any other object.
//SO here both statmenst are perfectly valid ,but
[(NSNumber *)[sequence objectAtIndex:aCounter] removeFromSuperview]; //This throws warning and lets u know removeFromSuperview shpuld'nt be called
[[sequence objectAtIndex:aCounter] removeFromSuperview];//here u wont get any warnig
I just wonder why the cast (NSNumber *) is needed?
It's not needed if the signature of the selector that's actually called at runtime is visible to the translation, and all selector signatures visible to the translation match for the selector that's called.
You're probably thinking "What? That's complicated! That's also error prone, especially as my programs evolve!"
If multiple selector signatures for the same selector are visible and you message id, then you should expect undefined behavior because objc collections aren't typed and the compiler may not match the correct selector (if your warning level is high and your includes are all correct, you can see a warning about this).
The simple way to avoid this is to reintroduce the correct type by assignment:
NSNumber * n = [array objectAtIndex:i];
int a = [n intValue];
or by casting:
int a = [(NSNumber*)[array objectAtIndex:i] intValue];
so the compiler can match the selector appropriately for the type, and also warn you when the object may not respond to a given selector, or if the parameters or return types do not match, or if the interface of the type you cast it to is not visible in the translation -- after all, you should have an idea of what the collection contains.
Introducing that type safety properly is a very good practice.
The cast is just needed to stop the compiler from complaining that it's not sure you know what you're doing.
One of the things that the compiler does for you as it compiles is to check whether the interfaces for the recievers of messages say that they respond to the messages you're sending (intValue in this case). The interface of NSNumber does indeed say that it responds to intValue, but the return type of objectAtIndex: is id, which is a generic pointer. The compiler has no way to know what the type of the object at the other end of that pointer is -- that won't be known until runtime.
The cast tells the compiler that you do indeed know the type and that it doesn't need to warn you (or, in some cases under ARC, give an error) about the fact that it's not sure if the receiver of the message responds.
Note that if you changed the class of the cast to something that didn't respond to intValue (such as NSDate), the compiler would gripe at you, but if the object really was still an NSNumber, the message would still succeed at runtime. Casting can't change the type of the object; it is simply an annotation for the compiler.*
*In some cases, it can also increase the readability of your code, too.
I have an NSMutableArray which returns me some object.
The object which I added had properties name,age.
now when I use these properties on the Object returned (obj.name or obj.age ),
Compiler says, no such member, use (->) instead of (.)
I understand that NSObject wont have these members and hence it wont understand the property.
But If i use setters, and getters as method ([obj name] or [obj age]) syntax instead of this properties, I dont get any errors.
But using property means calling a setter or getter only ?
ad Objective C is suppose to be dynamic language, right ?
Do you cast the returned object to your object type (MyObject)?
You should do something like:
((MyObject*)[mutableArray objectAtIndex:0]).age = 20;
The reason you're not getting any errors when using [[mutableArray objectAtIndex:0] name] syntax is that you're calling a method on the returned object (which is of type id), and id s tend to not choke in the compile-time if you call a (yet) non-existant method on them. At the run-time, [mutableArray objectAtIndex:0] might resolve to type MyObject an in that case, the message [obj name] has a proper implementation (IMP). If it doesn't resolve to MyObject, your app will crash.
And note that the reason you're not even getting a compile-time warning is that Xcode knows that there is at least 1 class in your codebase that implements the method name, and it trusts you with calling this method only on instances of that class. if you do something like ((MyObject*)[mutableArray objectAtIndex:0]).ageeeeee = 20;, it'll give you a warning as there's a very good chance that it'll crash (no class in your app implements the method ageeeeee statically).
The type id does not have a property name, and that's why you can't use dot syntax.
Actually, this incident shows perfectly why ObjC is called a dynamic language!
That's right - dot syntax is not supported in such case.
You need to cast a pointer to the actual class:
((MyObject*)[array objectAtIndex: 0]).name = #"Bill";
I want to know why id is a weak reference pointer,how it is able to handle any class type pointer and at run time how can we detect that which type of class pointer is assigned to id.
Why is id a weak reference pointer?
id is not a weak reference pointer, at least not in the ARC ownership sense. Whether an id-typed reference to an object is weak or not depends on the reference having been declared __weak (and variations) and the object’s class actually supporting weak references.
However, you could say that id provides weak typing, although I think that dynamic/duck typing is a more accurate description. Since an id- typed reference contains no compile-time class-type information, the compiler isn’t able to, for example, determine if the underlying object can respond to a given selector, which could lead to runtime errors.
How is it able to handle any class type pointer?
That’s part of the definition of the Objective-C language. The compiler recognises id as being the supertype of every Objective-C class, and it treats id differently. See the answer below as well.
At runtime, how can we detect that which type of class pointer is assigned to id?
In Apple’s Objective-C runtime, the first bytes in the memory allocated to an object must point to that object’s class. You might see this referenced elsewhere as the isa pointer, and that’s how Apple’s runtime finds out the class of every1 object. The id type is defined to have this information as well. In fact, its only attribute is the isa pointer, which means that all1 Objective-C objects conform to this definition.
If you have an id reference and want to discover the class of the referenced object, you can send it -class:
id someObject;
// Assign something to someObject
// Log the corresponding class
Class c = [someObject class];
NSLog(#"class = %#", c);
// Test whether the object is of type NSString (or a subclass of NSString)
if ([someObject isKindOfClass:[NSString class]]) {
NSLog(#"it's a string");
}
1Tagged pointers are a notable deviation of this structure, and (partly) because of them one shouldn’t access the isa pointer directly.
It's nice to have a generic object type, so you can define collection types that can hold any kind of object, and other generic services that work with any object without knowing what kind of object it is.
There is no trick to make id work. At a binary level all pointers are interchangeable. They just represent a memory address as a numerical value. To make id accept any type of pointer, it's only necessary to disable the rules of the compiler that normally require pointer types to match.
You can find out information about the class of an id type variable in these kinds of ways:
id theObject = // ... something
Class theClass = [theObject class];
NSString *className = NSStringFromClass(theClass);
NSClassDescription *classDescription = [NSClassDescription classDescriptionForClass:theClass];
But it's rarely necessary to do those kinds of things in code. More often, you want to test if your id variable is an instance of a particular class, and if so cast it to that class and start treating it as that type.
if ([theObject isKindOfClass:[MySpecializedClass class]]) {
MySpecializedClass *specialObject = (MySpecializedClass *)theObject;
[specialObject doSomethingSpecial];
}
If you were to use -class to find out the class, but it returned a class you know nothing about, then there's nothing special you can do with the object based on its class anyway. So there is no reason to do anything but check if it matches classes you know about, and only if you intend to do special handling for those classes anyway.
You can sometimes use isMemberOfClass instead of isKindOfClass. It depends whether you want an exact match or to include subclasses.
It may be worth to take a look on header file objc/objc.h to find internals of id.
typedef struct objc_class *Class;
typedef struct objc_object {
Class isa;
} *id;
typedef struct objc_selector *SEL;
typedef id (*IMP)(id, SEL, ...);
Would someone please clarify what the difference in these two snippets would be?
I know this is instantiation:
Class *myClass = [[Class alloc] init] ....etc
but what exactly is this?
(Class *)myClass .....etc
Thanks
The second snippet is either a cast or a parameter to a method. Neither have anything to do with instantiation.
If (Class *)myClass occurs in a method declaration, it just defines what type the parameter to the method should be. For example, - (void) method:(Class *)myClass is a method that returns void and takes one argument, of type Class*.
If (Class *)myClass occurs in other code, it's a cast. Basically it says to reinterpret myClass as a pointer to an object of type Class, regardless of what its type really is. It's like casting with numbers - if x is an int, (float)x casts it as a float so you can use it in floating-point arithmetic.
Generally speaking, I'd caution you against using casting heavily with Objective-C objects. One place you will see things like this is in casting NS objects to CF objects, as in (CFURLRef)[NSURL fileURLWithPath:path]. But most often objects of different types will not cast properly.
Also, you have an error in your first snippet. It would actually be [[Class alloc] init]. You must call alloc and then init. And [init] is meaningless - it doesn't fit the [object method] syntax of Objective-C at all.
The first one, given correct syntax is instantiating, as you say.
The second one is casting a variable "myClass" to a pointer to an instance of the Class object.
The second snippet is a C-style cast. It effectively tells the compiler to treat myClass as a value of type Class* regardless of its declared type. Without the rest of the snippet (and the preceeding declaration of myClass), it's impossible to say why you would want to use the cast or what effect it would have.