I'm new into Obj-C.
I would like to know will there be any problems if I assigning NSMutableArray to NSArray as like example code below:
NSMutableArray *mutableArray = [NSMutableArray arrayWithObjects:#"item1", #"item2", nil];
NSArray *array = mutableArray;
I know that if i use [mutableArray copy] it will duplicate the array as new set. My question is will my approach conflict with any guidance or will have any problems?
Thanks.
Both pointers will refer to the same object. The nature and behavior of that object will remain the same. It is not aware nor affected by which pointers refer to it.
If the array is mutated, those mutations will be observable regardless of which pointer you use to message or examine the array.
The compiler will complain if methods present in NSMutableArray but not NSArray are sent via the array pointer. However, if you ignore the compiler's complaints, the methods will still work as normal. The static types of the pointers is only significant at compile time. They are not represented in the compiled program (except, possibly, in debugging information, but that doesn't affect runtime behavior).
The catch is this:
if mutableArray changed somehow, and the array still think of it self immutable.
Then, things might get out of control.
Other than this, I don't see much problem here...
Your array will stay mutable, but compiler will think that it is immutable. So it won't allow you to use methods specific for NSMutableArray without typecasting.
Related
I have an XPC service compiled 32-bit for OS-X. One of it's methods takes a single argument as a parameter, and calls a given block back on the main process.
This block takes 3 NSStrings and an NSArray that's supposed to contain NSValues solely. Each NSValue object holds an NSRect.
For some reason, the given block is not being called when the NSArray is not nil.
If instead of holding NSValues I let the array hold NSStrings, the block is being called correctly.
I'm not sure how to approach this, as there is no apparent reason for this to happen. According to the apple documentation, NSValue does conform to NSSecureCoding.
I even tried whitelisting the NSValue class (this shouldn't really be needed) using:
NSSet *readerSelectionClasses =
[NSSet setWithObjects:[NSArray class], [NSValue class], nil];
[newConnection.exportedInterface setClasses:readerSelectionClasses forSelector:#selector(MyMethod:WithReply:) argumentIndex:3 ofReply:YES];
This doesn't seem change anything.
Any idea how to pass the NSArray? I guess I could format all NSRects to NSStrings, and pass an array of NSStrings, which I know works, but this would lead to a performance decrease I would rather avoid.
This might be a stupid question, but it keeps bothering me.
Say if we have a method that takes an NSString object as its parameter and does something with the NSString object,
- (void)someMethod:(NSString *)str
{
//do something with str
}
Consider this code
[someObject someMethod:[[NSString alloc] initWithFormat:#"Hello World!"]];
Since alloc has been used in creating the string as parameter of someMethod, it has to be balanced by release no matter explicitly in pre-ARC environment or implicitly under ARC. But it seems there is no way we can get a pointer to the string as we have never assigned it to any pointer.
So my question is, first, is this way of passing parameter prohibited in writing objective c code? If no, then how objects created this way get released? And finally, does this code lead to memory leak?
Just for the record, I understand the above code is written
NSString *string = [[NSString alloc] initWithFormat:#"Hello World!"];
[someObject someMethod:string];
// [string release]; depending on ARC or non-ARC
Well, in fact, that object is assigned to the variable named str, which is a parameter of your method. You can manage the memory inside your method via that pointer, although methods aren't supposed to take ownership of their arguments (except see below).
ARC knows what to do in this situation -- it will either autorelease the object or add a release once the method is finished.
Under MRR, your snippet would be a leak; the correct way to avoid that is also to send autorelease:
[someObject someMethod:[[[NSString alloc] initWithFormat:#"Hello World!"] autorelease]];
or to use your last snippet (putting the string into a temporary variable and releasing later).
As a slightly esoteric option, it is possible for your method to declare that it owns the argument, by using the ns_consumed attribute:
- (void)someMethod:(NSString *) __attribute__((ns_consumed)) str;
This indicates that your method should send release to the object before it returns -- ARC will also take care of that.
So my question is, first, is this way of passing parameter prohibited in writing objective c code?
No. It's perfectly legal.
If no, then how objects created this way get released?
ARC will take care of it for you. If you do your own reference counting, then you can add it to the autorelease pool before it goes out of scope:
[someObject someMethod:
[[[NSString alloc] initWithFormat:#"Hello World!"] autorelease]];
^^^^^^^^^^^
And finally, does this code lead to memory leak?
Not in ARC. In MRC, you would need to add the -autorelease.
The static analyzer would also point out that leak.
There's no reason to not write code as you ask for consideration on… nothing prohibited in the slightest. These objects get released in the same manner that any other object gets released. Your lack of a variable to store the pointer in at the top level isn't important because the Objective C runtime knows about the object.
I would like to ask all the Cocoa veterans out there - is there any difference in performance between using mutable versus immutable objects in cases like:
NSString's stringByAppendingString: versus NSMutableString's appendString:
NSArray's arrayByAddingObject: versus NSMutableArray's addObject:
...
Thank you and happy coding!
This question is hard to answer : NSArray and NSString aren't actual implementations, they are class-clusters and so are NSMutableArray and NSMutableString. The true implementations underneath can't be determined and thus performances would be hard to compare.
You probably won't find a definite answer to that one.
But what I would guess is : stringByAppendingString and arrayByAddingObject create new objects which contains the modifications, ie copy the current items to a new place in memory, NSMutableArray and NSMutableString should have better performances because they are built to prevent copying when possible (not actually true because NSMutableArray might recopy memory when elements are added but not every time).
I think you should trust the CoreFoundation coders on this one : you wan't to mutate objects ? Use the mutables one.
Today I was working on a project in which I wanted to "alias" an alternative method for all instances of NSArray, and didn't think it would be too difficult with some good old-fashioned method swizzling.
I broke out JRSwizzle and…
[NSArray jr_swizzleMethod:#selector(objectAtIndex:) withMethod:#selector(objectAtIndex_accordingToMe:) error:nil];
To be clear, I paired this with the appropriate category on NSArray, an instance method called objectAtIndex_accordingToMe:.
However, I was just getting that same old object, at that same old index. Sigh. Ultimately, I figured out that despite not throwing any errors - I'm not going to achieve these results due to the fact that NSArray is a class cluster
I guess my question is more of an unwillingness to accept that "this" is really the end of the road trying to override NSArray methods. I mean, come on this is NSArray.. people must wanna muck around with it, no? One would think that Apple's foundation classes would be a prime target for swizzlers, everywhere!
So, is there a way to alter, alias, monkey-patch, override, or otherwise have your way with… an NSArray, etc. (without subclassing)?
It's not just that it's a class cluster. NSArray is toll-free bridged to CFArray, and you can't swizzle Core Foundation. So this is very unlikely to work in general.
But what are you trying to solve? If you want to add a new method, use a category. They work on class clusters just fine. Modifying the behavior of some built-in on NSArray seems a recipe for disaster (entertaining as it might be as an exercise).
Before going too far, you probably want to at least take a look at CFArray.c and understand how some of the underlying stuff is implemented.
EDIT: While I would never do this in production code, you may get some of what you want by hijacking individual array instances with ISA-swizzling. See ISASwizzle for some example code. The code explanation is in Chapter 20 of iOS:PTL. Search out for "isa swizzle" and you should find more on the net. It's how KVO is implemented. But with NSArray... wow, that's gotta be fragile.
Presumably you have a particular array for which you'd like this behavior. You can get that instance's class object, no matter what it is, and swizzle that quite easily:
[[myArray class] jr_swizzleMethod:#selector(objectAtIndex:) withMethod:#selector(objectAtIndex_accordingToMe:) error:nil];
There's also only a few concrete subclasses of NSArray:
NSArray * trees = [NSArray array];
NSArray * birds = [NSArray arrayWithObjects:#"Albatross", #"Budgerigar", #"Cardinal", nil];
NSMutableArray * dogs = [NSMutableArray arrayWithObjects:#"Airedale", #"Beagle", #"Collie", nil];
NSLog(#"%# %# %#", [trees class], [birds class], [dogs class]);
We get __NSArrayI for the first two and __NSArrayM for the third, so potentially (this is very fragile) you could use a runtime function to grab the class object by name:
[objc_getClass("__NSArrayI") jr_swizzleMethod:#selector(objectAtIndex:) withMethod:#selector(objectAtIndex_accordingToMe:) error:nil];
Noob question:
I'm currently under the impression that when you want to create an object, you need to alloc and init that object.
However, I've seen seen several sample codes where an NSString object is declared, yet I see no alloc or init messages following...
A very simple example:
NSString *myString = #"Hello World";
NSLog(#"%#" , myString);
Can someone explain why this is so?
Declaring a variable does not require releasing any memory.
Instantiating objects does. And you only instantiate a new object if you call alloc or copy
In your example, you are setting your reference to the already existing object that the compiler creates from the hard-coded string. And you don't have to manage its memory because you didn't instantiate it.
I don't know if I'm explaining it clearly enough.
EDIT:
It looks like there is already a question that answers this:
Is a literal NSString autoreleased or does it need to be released?
When you embed an NSString literal in your code, such as #"hello, world', the compiler allocates space for it in your executable file and it's loaded into memory and initialized when your program starts.
Since it's part of your executable, it lives for the whole lifespan of your app. There's no need to retain or release it. The NSString *myString variable you create for it is a pointer to the place in memory where the compiler put the NSString literal.