This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
Use of alloc init instead of new (Objective-C)
Does any of you use +new of the NSObject to alloc & init the object?
Lets say i got an object C derived from Object B which all are from NSObject. To create an instance of Object C
C newInstanceOfC = [C new]; // This will call the alloc & init of class C.
is this any better than
C newInstanceOfC = [C alloc] init];
other than less things to type. What is good practice?
cheers
Arun
alloc] init] is best practice. In particular, objects have different ways to init, including zero, one or more than one parameter. Using new makes an automatic selection of init, but having init visible can help you troubleshoot some nasty bugs that can happen if you initialise a UI element but forget to set the frame, etc.. You'll get compiler warnings about the use of the init method in some circumstances too.
They are both exactly the same, new is the new way, as that wasn't possible before, but use the one that you like the most.
I usually use new since it is shorter, although in several cases you can't since you usually want to do something like:
[[myObject] alloc] initWith...];
Related
Hey guys I just have a simple objective c question, I have been looking over my companies code base and I have stumbled upon something interesting. When should you use [[alloc] init] and when should you not. Here is a classic example:
Case 1:
NSString *url = nil;
url = #"hi";
Case 2:
NSString *url = [[NSString alloc] init];
url = #"hi";
So when should you use Case 1 and when should you use Case 2? I am hoping someone can settle this for me once and for all, throughout my app development I have been using Case 2 because I thought it was equivalent to calling a "new" in C++ (basically invoking an objects constructor). I am shocked that Case 1 even works, because Case 1 indicates no invokation of a constructor or memory allocation for that object. Case 1 is used everywhere in the code base I am looking at though.
alloc creates storage and does some basic automatic setup, returning an instance of the class. init allows the instance to configure itself as per the logic required for that class. = assigns a different instance to the pointer.
So the first is always correct, the second always incorrect. There's no point creating an instance of an object then throwing it away one line later.
(aside: with ARC you can always skip the = nil as it's implied; in your case you could skip it regardless because of the following assignment)
#"hi" creates an instance of NSString. It does the allocation and initialization. Therefore, in case 2, you are pointlessly allocating memory and then reassigning the "url" pointer to a new piece of memory.
You have to remember that "url" is a pointer. Just like in C or C++, when you use the "=" operator you are reassigning where it is pointing, you are not affecting the memory it used to be pointing at. In C, if you want to change the value stored at the newly allocated memory, you would have to use the dereference operator.
alloc creates an object. So you use it when you want to create an instance of a class. In this case, you do not want to create an object, because you're going to assign the existing object #"hi" to the variable. So you would never write Case 2, as it creates an object and immediately discards it for another object.
I thought I had a decent understanding of objects, but I guess not. What happens when two objects are the same name? They are both pointing to the same location in memory? So if I had one class that said:
SomeClass *someObject = [SomeClass new];
someObject.text = #"test";
And another class instantiates the same object with the same name:
SomeClass *someObject = [SomeClass new];
someObject.textColor = [UIColor redColor];
This would modify the same object to be a red text that says "test" right ?
Thanks!
~Carpetfizz
No, those two pointers point to two different objects in the memory. It doesn't matter if they have the same name. They were allocated and initialized separately in two different classes.
Btw, you should never use the new method to allocate and initalize the object. The new message is discouraged, as allocation and initialization are two different processes. You should use this instead:
SomeClass *someObject = [[SomeClass alloc] init];
Nope. Just because two variables happen to share the same name does not mean they share the same memory location. When this compiles, the compiler strips the variable names (but not the class names) and calculates memory offsets and messages instead of names and classes. Besides, as a local variable, as soon as they pass out of scope -most likely at the end of each function that created them- they will be destroyed immediately.
No. You can't do that.
Any modern-day compiler will attempt to strangle you before compiling that code - for that exact reason: It doesn't know what to do!
Even if you could get the compiler to make it work, just because the two objects have the same name doesn't mean they have the same memory address.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
What do the plus and minus signs mean in Objective C next to a method?
What's the difference between using a plus or minus in Objective-C?
For example, most of the time code starts -(void)somethingSomethingelse, but sometimes it will be +(void)somethingSomethingelse
Thanks!
- functions are instance functions and + functions are class (static) functions.
So let's say you have a class called Person, and the following functions
-(void)doSomething;
+(void)doSomethingElse;
You would invoke these functions with the following:
Person *myPerson = [[Person alloc] init];
[myPerson doSomething];
[Person doSomethingElse];
This is more of a syntax description, assuming you understand the concept of class vs instance.
edit:
just to add: In objective-C, you can actually invoke a class function on an instance, but the effect is no different than invoking it on the class itself (essentially compiles to the same thing).
So you can do
[myPerson doSomethingElse]
Generally, you wouldn't do this as it is confusing and misleading to read. I am pointing it out so you won't be surprised if you come across code like this somewhere.
In short, (+) is a class method and (-) is an instance method
See this answer for a full explanation
What is the difference between class and instance methods?
member and public functions respectively.
Such that
id object = [[NSObject alloc] init];
+ (id)alloc;
- (id)init;
Where NSObject is a Class and id is an object
If you have ever used C++, a + is equivalent to static
NSArray *array = [dictionary objectForKey:#"field"];
and
NSArray *array = [[NSArray alloc] initWithArray:[dictionary objectForKey:#"field"]];
I see both kind of approaches very frequently in objective C code.
When tried to understand, I found both of them used in similar situation too, which makes contradiction. I am not clear on when I should use 1st approach and when 2nd one?
Any idea?
Detailed explanation and useful references are moms welcome.
First off, those two examples are doing slightly different things. One is retrieving something from an existing dictionary and one is creating a new array by retrieving something from an existing dictionary (the value of that key is an array).
But, if you're asking the difference between getting objects by alloc vs. convenience methods. ([NSString alloc] init vs [NSString stringWith ...), by convention, you own anything that you call alloc, new copy or mutableCopy on. Anything that you call that is not those, is autoreleased.
See the memory guide here. Specifically, look at the rules.
Getting an autoreleased object means it will go away at some point in the near future. If you don't need to hold onto outside the scope of that function, then you can call autorelease on it or use one of the convenience methods that's not alloc, etc...
For example:
// my object doesn't need that formatted string - create the autoreleased version of it.
- (NSString) description {
return [NSString stringWithFormat:#"%# : %d", _title, _id];
}
// my object stuffed it away in an iVar - I need the retained version of it. release in dealloc
- (void) prepare {
_myVal = [[NSString alloc] initWithFormat:"string I need for %d", _id];
}
In the first example, I created a convenience methods for others to call, my class doesn't need that object beyond the scope of that method so I create the autoreleased version of it and return it. If the caller needs it beyond the scope of his calling method, he can retain it. If not he can use it and let it go away. Very little code.
In the second example, I'm formatting a string and assigning it to an iVar variable that I need to hold onto for the lifetime of my class so I call alloc which will retain it. I own it and releasing it eventually. Now, I could have used the first version here and just called retain on it as well.
You have a fundamental misunderstanding of allocations versus instance methods.
The first example, NSDictionary's -objectForKey method, returns id, not an instance of NSDictionary, therefore it does not allocate or initialize the variable.
The second, however is the classic retain part of the retain-release cycle.
The two methods are fundamentally equal (if we are to assume that array is alloc'd but empty in the first, and nil in the second), and both get ownership of the array object. I would go with the second, as it guarantees a reference, and it's shorter.
What I think you're confusing this with are new and convenience methods. Convenience methods (like NSNumber's +numberWithInt:, NSString's +stringWithFormat:, and NSMutableArray's +array), return an autorelease instance of the class (usually). New takes the place of alloc and init in just one word.
This question already has answers here:
Difference between self.var and simply var
(3 answers)
Closed 8 years ago.
What is the difference between self.myVariable = obj; and myVariable = obj;, when I use #propery/#synthesize to create `myVariable?
It's important to note that dot-syntax is converted to a simple objc_msgSend call by the compiler: that is to say that underneath it acts exactly like a message send to the accessor for that variable. As such, all three of the following are equivalent:
self.myVariable = obj;
[self setMyVariable:obj];
objc_msgSend(self, #selector(setMyVariable:), obj);
Of course, this means that using dot-syntax actually results in a full message send, meaning calling a new function and all the overhead that is associated with it. In contrast, using simple assignment (myVariable = obj;) incurs none of this overhead, but of course it can only be used within the instance methods of the class in question.
The #synthesize directive tells the compiler to generate accessors for your member variables, according to the specifications given in the #property directive in your .h file. (I.e., if you specify retain, the setter will retain the variable, and if you specify copy, it will copy it.)
The accessors will (unless you specify otherwise) be named propertyName and setPropertyName.
Using the . notation (note, not the self syntax as stated above) is saying that you want to use the accessors (a good thing if you are setting strings, and want to ensure the retain count is correct, for example).
So, within your class implementation:
self.bill = fred will call the
accessor setBill.
bill = fred will set bill to fred
directly, without going through the
accessor.
One of the differences I found out when starting Cocoa development is if I set variable to use a #Property/#Synthesize syntax and I didn't use self.myVariable = obj or [self setMyVariable:obj] but instead myVariable = obj, the object is not retained if obj is released later. (Assuming #Property was set up to use retain.)
The reason is the retain count is not set when using myVariable = obj and when the obj is released the count is now zero. (Unless you retain it yourself) But by using the accessor it will do the retain count for you. (Again assuming you set it up to use retain when it was declared).
Shyne
If I can add one important note to this. The answer above are all awesome, so I won't add to the technical side. But just this:
If you create a synthesized property
#synthesize myProp;
Always use the self.myProp pattern to set it.
self.myProp = newVal;
This seems really obvious, but it's important. It's true that there is simply no reason to do this, but until you really understand how the synthesized setters are created you just want to assume you HAVE to use the self. pattern to set the value.
Honest: this will save you a lot of late night debug sessions. Non-retained memory access violations are simply the worst to debug.
The self syntax uses the accessor method, the other syntax does not. This might be a big difference if the accessor does something more than simply assign the new value. See the Declared Properties part of the Objective-C tutorial.
The other answers are correct, the difference is that the dot notation causes the ivar to be changed through the accessory rather than directly.
Until you know what you're doing, I recommend you use the dot notation (i.e. self.propertyName = ...). Cocoa/Obj-C does a lot with key-value coding, and while the phone SDK doesn't take full advantage of that (with things like bindings), eventually it will. Getting used to using the accessors now will save you a lot of headaches in the future.
Using the accessor methods also give you the opportunity to override them and provide more functionality should you need to. By simply changing the value of the ivar, you rob yourself of this capability.