I know there are differences between C/C++ and Objective-C, but what is the case when it comes to the pointer-mark *? Is this not used for pointers in Objective-C, or are all objects pointers in this language?
I.E, if I try NSString string = #"Hello";, XCode tells me to use NSString *string instead. Does this still mean it is a pointer?
Let's say I have this standard method(as in, this is the way most methods look):
-(void)method:(NSString*)s;
then I would send something like this:
NSString *string = #"Hello";
[self method:string];
Would I save data time or allocation or access or whatever by doing everything like this:
-(void)method:(NSString**)s;
//and use it like this:
NSString *string = #"Hello";
[self method:&string];
Or is it a waste? If they are already pointers, I would guess they would be pointing to pointers this way.
?
Objects themselves aren't pointers, they're areas of memory with data in them. The variables you're talking about are pointers to those objects:
NSString *string = #"Hello";
Here, 'string' is a pointer to anNSString literal object. When passing this as a variable you're passing a reference to the object. The contents of the object (if it's a mutable object, which NSString isn't) can be edited, but the reference can't.
By using NSString ** you're adding an extra level of indirection. Now you're passing a pointer to a pointer. The only reason you want to do that is when you want to allow the object (if there is one) to be edited as well as the reference to the object. For example, when calling a method that optionally returns an error:
NSError *error = nil;
[someone doStuff:(NSString *)string error:(NSError **)error];
Now someone can instantiate an NSError and return it to you.
You should not use pointers to pointers unless this is your intention.
Related
I ran into some old code in a project and I do not understand why it does not crash.
Data is being ingested from an HTTP request to an API and certain values are returned as strings, but treated as NSNumbers. For example, in the code below, value is an NSString.
[NSDecimalNumber decimalNumberWithDecimal:[(NSNumber *)value decimalValue]]
However, it is incorrectly cast to an NSNumber and the decimalValue method of NSNumber is called. There is no decimalValue method for NSString, so I don't understand why the line above does not cause a crash. When I inspect value with [value isKindOfClass:[NSString class]] and [value isKindOfClass:[NSNumber class]] I get the expected results.
Is there a behavior of the runtime I do not understand? Does a cast cause the methods of a different class to be used?
edit
I'm updating the title of this question to more accurately reflect the issue. The answer was that NSString has a private decimalValue method that was causing the confusion.
The real answer? Voodoo. Not really, but sort of.
Lots of classes in cocoa have private methods behind the scenes. Usually, these methods go mostly unnoticed, and even more rarely used.
However, if you grab their implementation using class_getMethodImplementation and use dladdr to print the location of the symbol as such:
IMP theImp = class_getMethodImplementation([NSString class], #selector(decimalValue));
Dl_info info;
dladdr(theImp, &info);
puts(info.dli_sname);
You should see something like -[NSString(NSDecimalExtension) decimalValue].
My best guess is that this method is used for KVO & friends when marshaling values to/from decimal values, or it's used with NSNumberFormatter.
I have a question about the parameter that #synchronized take, I have read the Apple document about synchronisation but still I don't have a clear idea.
I have a case that #synchronized will take a string property inside some object like this :
#synchronized(someObject.A)
since A is a NSString object and in some cases will carry the same value but from different someObject is this will guarantee the locking for all objects with same A values?
It's worth noting that NSString has some special cases that are handled magically.
NSString *s1 = #"Test string";
NSString *s2 = #"Test string";
Here, s1 and s2 are actually compiled to access the same memory address, even though they are different variables and could be instantiated in completely different places within the application.
However, if you are loading the data on-the-fly or using one of the construction methods for NSString instead of hard-coding it, strings that match character-for-character will not share the same memory.
You can consider this the difference between comparing with == and isEqualToString:. #synchronized only ever uses the == result.
So, to answer your question: maybe.
If you are using hard-coded values of the form #"some string" within your application, your #synchronized command will link to all objects that share the same textual value for A.
If you are creating NSString objects by any other means, your #synchronized command will only link to objects that point to the exact same NSString object.
The synchronization will be done on whatever object someObject.A is currently referencing. The important piece is the actual object you use #synchronized on.
If you assign the same string to two completely difference properties and you then use #synchronized on those two completely different properties, it will work since both point to the same string.
The following example may help:
// In one method
#synchronized(someObject.A) {
}
// In another method
NSString *foo = someObject.A;
#synchronized(foo) {
}
The above two blocks will be thread safe on the same string object.
I am used to the simple way of initialising NSArray.
NSArray *temp = [[NSArray alloc] initWithObjects:#"data1",#"data2",#"data3",nil];
I have now come across code in a non arc app where initialisation is done at many place like
NSArray *temp;
temp = [#[#"data1",#"data2",#"data3"] retain];
Can anyone elaborate the difference between two and if one is better than other.
Thank you
The second is using the new(ish) Objective-C Literal syntax.
This literal syntax allows simplified creation of NSNumber, NSArray and NSDictionary objects as well as providing subscripting support for arrays and dictionaries.
The second one is just a shortcut for:
+ (instancetype)arrayWithObjects:(id)firstObj,...
This
#[#"data1",#"data2",#"data3"];
will be compiled like:
[NSArray arrayWithObjects:#"data1",#"data2",#"data3",nil];
You can't say one is better than the other, they are made for different purposes. The shortcut syntax was invented to create arrays with content faster. You can see the shortcut is less code then the full arrayWithObjects example.
There are other shortcuts as well:
#{key: object}
to create a NSDictionary.
#YES #NO #value /* like #35 */ #(x + y)
to create a NSNumber
The first statement instantiates an NSArray object. In practice, you rarely see this code because NSArray objects are immutable and it's useless to have an array object with no elements that you can't change. It's more common to have
NSMutableArray *temp = [[NSMutableArray alloc] init];
or something similar and then add objects to the array later.
The second case declares a new variable of type NSArray and assigns it to an array of three NSStrings and then retains this NSArray object. This new array is immutable, like before, so it can't be changed. By sending the retain message, the retain count of that object will be incremented and the object will not be deallocated until it is sent a release. Without the retain, the object is owned by something else, probably an autorelease pool, in which case it will be deallocated when the method returns.
I am trying to wrap my head around NSString and NSMutableString, and how they affect memory.
In my research, I've concluded that if I create an NSString object and give it a value, then change the value later, the original object is replaced by another with the new value.
My question is, in the case of changing the value of an NSString. When the value of the NSString is changed and the object pointed to is replaced by a new object, what happens to the original object? Is this a memory leak?
Thanks! V
NSStrings can contain string literals, which are compile time constants, and string objects, which instead are instantiated dynamically at runtime.
In case of string literals, there is no dynamic instantiation, so they won't affect memory at runtime. Assigning a literal value to a NSString variable
NSString *myString = #"string1";
then assigning another literal value
myString = #"string2";
doesn't make any change to the amount of available memory.
In case of string objects instead memory does change. If you have a variable of type NSString and assign it a dynamic string, such as
NSString *myString = [NSString stringWithFormat:#"String %d", 1];
a new NSString instance is allocated, initialized with the provided string, and assigned to the myString variable.
If later you assign a new dynamic value
myString = [NSString stringWithFormat:#"String %d", 2];
a new NSString instance is created, but it doesn't replace the old one. Both are instantiated and in memory.
When using ARC though the first NSString instance, if no longer referenced, will be released because not being used. This is handled automatically, so nothing must be done from code.
Maybe you're more interested in the fact that at some time the new and old instances use memory - but that's temporary until the unused instance is released.
To answer to your concern, no, there is no memory leak. String literals persist for the entire app lifetime, since they are constants. String objects are allocated and released (deallocated), and deallocation is automatically handled by ARC.
Of course this is a general concept that applies to any dynamically instantiated class, not just NSString - but doesn't apply to primitive data type (int, boolean, float, etc.), because variables of those types hold the actual value, not a pointer to the area in memory where the value is. In case you are wondering, primitive data types don't generate memory leaks.
The original NSString will be released by the system and so, won't cause any leak.
It looks to me like sending setString: to a NSMutableString that hasn't had init called on it yet does not call init on it's own. For example:
NSMutableString *string; // Declare, but do not init yet
[string setString:#"foo"];
NSLog (#"%#",string); // Prints "(null)"
I'd like to overwrite this behavior, so that essentially
- (void) setString:(NSString *)aString
{
if (!self)
{
self = [self initWithString:aString];
}
else
{
[super setString:aString];
}
}
I could do so with a subclass, but I would have to go through my project and replace all my NSMutableStrings with my subclass, which is a pain. I was looking at the Apple Docs and it looks like what I want to do is create a Category for NSMutableString. I haven't used categories before, so I got a couple questions:
First, it looks like categories only allow me to add new methods, it doesn't allow me to overwrite existing methods. I suppose it is easy enough to just create a setStringWithInit: method that does what I want, so this first issue isn't really an issue after all (although I still have to do a find-replace through my project for setString, but oh well).
Second, and more importantly, how do I check if the sender of my new method is nil? If setString: returned something other than void, I think I could get it to work, but that's not the case here. How do I get the if (!self) check from my code above to work with a category?
Or are categories not the way to go for this kind of thing, and I'd just be better off sub-classing after all?
EDIT:
So the strings I'm using this on will actually be #propertys of a custom NSObject subclass. In my code, I'll actually be calling [myObject.someProperty setString:#"foo"];, and the debugger is showing me that someProperty is nil when I try to do this. Also, in other parts of my app I'm checking if (!myObject.someProperty) to see if that property has been used yet, so I don't want to just automatically self.someProperty = [[NSMutableString alloc] init]; in the init method of myObject's class.
Although now that I think about it, I think I can get away with replacing if (!myObject.someProperty) with if ([myObject.someProperty length] == 0), which would allow me to go through and alloc-init things right away. But if I'm initializing everything right away, that will create some memory space for it, correct? It's probably negligible though. Hm, perhaps this is what I should be doing instead.
The proper code would simply be:
NSMutableString *string = [NSMutableString string];
[string setString:#"foo"];
NSLog (#"%#",string);
Why would you not initialize the variable? There is no need to override setString: or any other method. Don't try to treat NSMutableString any differently than any other class.
Besides, overriding setString: still won't solve anything. As long as the pointer is nil you can't call a method on it.
You are marching down a path to madness. Abandon hope, all ye who enter here!
Do not try to change the language semantics so that sending a message to a nil object somehow magically creates an instance of the object. That is not how the language works.
What you are trying to do is likely impossible, and if you were able to succeed, you would create programs that are fundamentally incompatible with standard Objective-C. You might as well found a new language, Objective-D
It is legal to send a message to a nil object in Objective C. The result is that the message gets silently dropped, and nothing happens. In many other object-oriented other languages, sending a message to a nil object/zero pointer causes a crash.
The semantics of of Objective C object creation are:
First allocate memory for the object using the class method alloc:
NSMutableString* aString = [NSMutableString alloc];
Then send the newly created object an init method to set it to its initial state:
aString = [aString init];
These 2 steps are just about always combined into a single line:
NSMutableString* aString = [[NSMutableString alloc] init];
Classes sometimes include shortcut "convenience" methods that do the 2 step alloc/init for you, and return an object in one call, e.g.:
NSMutableString *aString = [NSMutableString stringWithCapacity: 50];
Do not try to fight this convention. Learn to follow it. If you cannot tolerate this convention, program in a different language. Really.
You can reimplement a method without subclassing by using method swizzling. Here's a tutorial. There are 2 reasons not to do it here though.
it would be against the good Objective-C practices, since your
setter will also be an init method. Not good.
As #rmaddy correctly points out, calling setString: on a nil object will do
nothing. Even if you do override the method.
So I recommend creating a category on NSMutableString, and implementing [NSMutableString initWithString:] there. It is a much cleaner solution.
You cannot really do that - you have a method which can be called only on instance of this object, so you will have to create it first anyways to use it.
In your code it will be "nil" anyways - it won't create itself.
Why are you doing it instead of just:
NSMutableString *string = #foo";
I cannot imagine a reason to avoid allocating an object
macros FTW!
#define setString(X,Y) if(!X){X=[[NSMutableString alloc] initWithString:Y];}else{[X setString:Y];}
When I try to assign a value with this:
It will always be initialized first
It won't be initialized until I try to give it a value
It doesn't clutter up my code
It still gives a warning if X isn't an NSMutableString, or if Y isn't an NSString or NSMutableString
I haven't tested for if Y is nil, but I expect it will cause a crash, which is what I want.
Drawbacks:
I still have to remember to always use my setString() instead of the stock setString:
I'll have to do something similar for any other setters I call (the only one that I'm worried about off hand is setValue:forKey:, which I use extensively - one step at a time I guess) - a one size fits all solution would have been nice - maybe a topic for another question.
Whatever I pass in has to be a NSString before I pass it, I cannot convert it to a string in line - but at least I get a build error if I try to do so, so it isn't up to me to remember to do so (still adds clutter though)
NSMutableString *X;
int y = 0;
setString(X, [NSString stringWithFormat:#"%d",y]) // <--- Doesn't work
NSString *Y = [NSStirng stringWithFormat:#"%d",y];
setString(X,Y) // <--- Does work