first post. Sorry if I screwed up the code rules. I'm trying to learn Objective C from the Big Nerd Ranch Guide. I'll post the example dealing with strong references.
#import <Foundation/Foundation.h>
#interface Asset : NSObject
{
NSSTRING *label;
unsigned int resaleValue;
}
#property (strong) NSString *label;
#property unsigned int resaleValue;
#end
So basically the NSString needs a strong reference whereas the int does not. I'm aware that NSString is an object, and I've read that if nothing is specified a variable is given the property of assign.
So if assign is good enough to keep something like an int from being freed until the object owning it is freed, how come it's not good enough to keep the NSString object within the Asset object from being freed? Ultimately I guess I'm still confused about what assign does in terms of reference counting vs. what strong does (or perhaps I should say retain since that is what strong replaced in ARC).
strong == to std::shared_ptr if you come from C++
strong states that the object must be retained and released respectively during assignment.
-(void)assign:(id) b to:(id) a {
if( b ){
[b retain];
}
if ( a ){
[a release];
}
a = b;
}
To answer your second question, the size of an objective-C object is not defined like a structure. Thus obj-C classes can not be held by value.
Thus all data inside of an obj-c class compiled as obj-c will always have plain old data types stored within it since their size can be determined as fixed.
Consider a buffer of 8 bytes;
The first 4 bytes are for your int the second 4 bytes are your pointer, since having a variable length string would change the size of the object at run time you see how this wouldn't work, a string is allocated on the heap and assigned to your pointer.
Related
I am new to iOS programming, I am preferring Swift language and I don't know Objective C. While I am wandering through some library, I got a value of type UnsafeMutableRawPointer in swift, that is actually a String value with utf8 encoding.
So I just looked into the corresponding objective c class and the variable is declared as
#property (readonly) void *data;
So why there is void pointer and why it is converted as UnsafeMutableRawPointer?
Consider me as a noob in Objective c or c.
Thanks in advance
This whole thing might be quite a lot for a beginner to understand. So let's start with ObjectiveC syntax:
Property #property (readonly) void *data; exposes interfaces which says there must be a method of type - (void *)data which means an instance method returning a void pointer. A void pointer being a pointer to anything.
ObjectiveC is then kind of a pure C a level deeper. I will not check exact transformation but since C has no methods this is all done with functions or even pointers to functions. So somewhere down there there should be a function (let's say the name of this class is MyDataClass)
void *myDataClass_data(MyDataClass *self) { return self->_data; } // Or whatever the implementation is
So nothing really interesting is going on under the hood. The whole thing just returns a position in memory without any further information of what should be there. You as a developer must know and interpret it. From C (or ObjectiveC) this is very simply. A few examples:
char *aString = (char *)myDataClass.data; // A pure C string. Expected to be null terminated
int *arrayOfIntegers = (int *)myDataClass.data; // An array of integers
int thirdItem = arrayOfIntegers[2];
MyDataClass *nextItem = (MyDataClass *)myDataClass.data; // A pointer to another instance
for(MyDataClass *iterator = myDataClass; iterator != nil; iterator = (MyDataClass *)iterator.data) {}
I hope you get the picture. The point is that C and then also ObjectiveC are very unsafe when it comes to data types. You can basically convert anything into anything however you want it and it will compile. The problem is what will happen in runtime.
When looking at Swift things get much safer and you can not just say something like let integer: Int = myDataClass as Int. You can force cast it and it will crash. Or you can do optional cast and it will return nil.
So once transitioned from C/ObjectiveC you will receive an unsafe mutable raw pointer. That means it got a position in memory witch it has no idea about what it is and how to use it. You may try to convert it to anything you want but it is unsafe as it will ignore all type checking. It is mutable probably because data it holds may be changed at any given time by any system. It is raw as it holds no additional information (like it's a string). And it's a pointer because it only points to a position in memory.
(All the snippets are symbolical to explain what goes on under the hood. Please do not take them literal)
Could someone please clarify exactly what ARC manages? Ive heard it does not manage c-structs, but i still see people using them. Please tell me which of the varialbes below will be managed by ARC and why.
static CGPoint _var1;
int _var2;
#interface class1:NSObject
CGPoint _var3;
CGPoint _var4;
NSString *_var5;
NSString *_var6;
}
#property (assign) CGPoint var3;
#property (strong) NSString *var5;
#end
#implentation class1
#synthesize var3 = _var3;
#synthesise var5 = _var5;
#end
ARC manages Objective-C objects automatically. All other types are managed just as they always have been in C.
Note that in your example, there is no allocation associated with the CGPoint instance variables; there memory is effectively allocated inline with the object.
Compared to MRC (as opposed to GC - which is now deprecated) ARC manages Objective-C objects - no retain, release or autorelease.
In general it does not manage core foundation objects - for those CFRetain and CFRelease are still required.
ARC does not manage C objects allocated with malloc and friends, for those manual memory management is required.
C structures are not dynamically allocated, they are value types just like integers and characters. If you declare pointers to C structures and dynamically allocate them using malloc and friends then you manage those manually as with any other dynamically allocated C object.
What you have have heard about in relation to ARC and C structures is a change to what field types are allowed. Under MRC the declaration:
typedef struct
{
int count;
NSString *name;
} Item;
is valid and name is managed manually using the usual retain etc. However with ARC it is disallowed, no object reference managed by ARC may be used as a field type in a structure.
The recommended alternative for the above structure is to use an Obj-C object instead. However if you really need value semantics the field can be marked with the __unsafe_unretained attribute:
typedef struct
{
int count;
__unsafe_unretained NSString *name;
} Item;
This attribute instructs ARC to ignore any reference stored into the name field for the purposes of determining whether an object should be retained or released. ARC may at any time release an object referenced by name, hence unsafe & unretained. To use such a structure safely you must ensure that the object referenced is kept around by others means, e.g. by having a strong reference to it that ARC is managing.
With XCode 3 compiler, I could manage an array of objects like:
#interface myView:UIView
{
CALayer *layer[4];
}
#property (nonatomic,retain) CALayer **layer;
#end
#implementation myView
#dynamic layer;
- (CALayer **)layer { return layer; }
// I could then access elements like
- (void) example
{
self.layer[3] = NULL;
}
#end
With XCode 4 compiler the #property declaration generates an error "Property with retain must be an object type".
I guess best way to fix is to convert to NSArray, but I have 100's lines of code using the c-style array subscript (e.g., self.layer[i]). Is there some other way to fix?
Several problems with this code:
It should be MyView, not myView; classes start with capital letters.
CALayer ** is not an object type; it is a pointer to an object type, hence the compiler complaint. Simply making it assign will make it compile, but it'll still be wrong.
There is likely no reason to use a language array (MyClass foo[4]) to hold this data. Use an NSMutableArray (you can use [NSNull null] as a stand-in for "this slot is not populated".
If you really want to stick with the language array, drop the retain. Just remember that you have to explicitly manage the retain/releases of the objects within the array. The #property won't do that for you.
Also, while it may seem a pain to fix your code to be inline with typical standard patterns, it is only going to be more costly to do so as the code evolves and, someday, you'll likely be in a situation where you really need to do so....
Change it to an assign property so you don't try to retain a non-object?
You cannot use Objective-C memory management calls (i.e. retain) on a C array. You need to manage your array using standard C or C++ logic. You need to malloc and free memory on your own. If you do not need to retain the array then you can remove the retain property.
I've struggling with the memory of my app (alloc, retain, release, etc...) for a while, but there's something I dont finish to understand.
If I declare this in my .h file:
int ex1;
char ex2[10];
What is the life cycle of these variables? Imagine that I want to use these variables in different parts of my .m code, in methodA I'm going to assign a value, and in methodB I'm going to read them.
Can I be 100% sure that the variables are not going to be released in any moment of my .m?
Thanks
As they are primitives, yes. They will not be retained or released. If you want to declare them as properties, you should declare them as:
#property (assign) int ex1;
and
#property (assign) char ex2[10];
Then in your .m file #synthesise them as normal and you will be able to use [myObject ex1] and [myObject ex2]
The idea is really quite simple in Objective C -
if you ever call alloc on an object then you are responsible for calling release on it.
If you ever call retain on an object then you are responsible for calling release on it.
If you want to make sure that noting else is going to release it from under you, and you didn't alloc, then call retain on it.
Obviously, however these rules apply to pointers to objects, not primitives like int or char.
You shouldn't be declaring variables in a .h file as this can lead to linker errors.
rather you should extern-declare them in the .h file and declare them properly in a .c/.m file. For example:
// In the .h
extern int ex1;
extern char ex2 [10];
// In the .c/.m
int ex1;
char ex2;
The reason being is that multiple .c files can include your header and you will have multiple definitions of the same variables.
Also, bare in mind that Objective-C is a strict superset of C. This means that anything that works in C works the same way in Objective-C. You only need to worry about retain/release/autorelease for Objective-C objects, basically anything that uses this syntax:
#interface MyObject : NSObject
{
// My vars
}
#end
I really need some clarification — I have a few questions and I'm all mixed up right now.
Here is a simple class interface:
#import <UIKit/UIKit.h>
#interface Car : NSObject{
NSInteger carID;
NSString *carName;
}
#property (nonatomic, assign) NSInteger carID;
#property (nonatomic, copy) NSString * carName;
#end
Why is carID not declared as a pointer?
Why does it use "assign" for carID instead of "copy"?
Why even declare class members as pointers in the first place? (In my main program, my Car object will be used as a pointer.)
NSInteger is simply a typedef for a primitive type (int on 32-bit, long on 64-bit) — it is not an object, and can as such not be retained or copied.
Class members are always pointers; you never pass the "real" objects around; as that would be, at best, unmanageable.
Edit: To expand on the last paragraph: Objective-C class instances always exist on the heap, never on the stack; this is to facilitate things like reference counting and self-managed object life cycle.
This also means that it's very hard to accidentally copy an object; but on the flip side it can be somewhat easier to accidentally dispose of an object you still need. Still, the latter is more readily debugged (as it causes a nice, big crash (at best, anyway)) than the last (which at worst causes a slow leak).
The property for carID is not really correct. For types that are not pointers, the correct definition looks like:
#property (nonatomic) NSInteger carID;
It's always going to be copying a value anyway, but "copy" has a very different meaning in properties - for objects it's going to call [object copy] when that property is used to set a new value.
Or you could drop off the nonatomic, but then the property is more expensive to call (by some small amount). Just leave in the nonatomic unless you have a good reason not to.
Thanks guys!
So in Objective-C , you have int and Pointer Int.
How do you declare these in objective C
-int being a regular int.
-Pointer Int being an object representation of an integer. Since it is an object, it can also point to pointers*. Right?
And Pointer Int pointers can point to pointers of any type If I wanted to. Right?
It will cause a crash if it doesn't point to a Pointer int. But it will compile successfully, Right?
But in what scenarios would I prefer using a regular int to a Pointer Int?
I would like to add some clarification why you would want to use:
#property (nonatomic, copy) NSString * carName;
instead of
#property (nonatomic, retain) NSString * carName;
The copy keyword implies language semantics that you want to have a COPY of the NSString passed into your current object reference. So the pointer does not change (that is why you don't have to release the object ref).
The retain keyword makes it so that you get the pointer which will be retained because the pointer reference changes for this data member (and the current one will be released). Copying a NSString might not be a considerably heavy operation, so copying NSString is used often. You have to be careful what type of property you declare as copy. There might be a considerable amount of effort to produce a copy of types like Dictionaries etc (see shallow, deep copy etc).
Hope that helps!