Become a MacRumors Supporter for $50/year with no ads, ability to filter front page stories, and private forums.

larswik

macrumors 68000
Original poster
Sep 8, 2006
1,552
11
I am trying to see if there is something in an NSTextField. I boiled it down to just giving a yes or no NSLog response to check it. If it returns no I ask it to print what is there, and it is printing nothing?
Code:
- (IBAction)openDeathCertWindowButton:(id)sender {
    NSString *test = @"";
    xyz = [nameArray count];
    
    if ([totalXpField stringValue] == test) {
        NSLog(@"Yes");
    }
    else{
        NSLog(@"No");
        NSLog(@"it says:%@",[totalXpField stringValue]);
    }
}

This is what is printed in the console
This GDB was configured as "x86_64-apple-darwin".tty /dev/ttys000
[Switching to process 809 thread 0x0]
2011-08-03 14:34:21.324 Xp Calc2[809:903] No
2011-08-03 14:34:21.325 Xp Calc2[809:903] it says:

This seems so simple. What am I missing? I have gray'd out placeholder text as default.
 
I understand. So the == 'Equal to' operator is only to be used to compare numeric values. I have never tried to compare strings before. I read the doc, it explained it.

Thanks for clearing that up balamw
 
Is totalXPField an NSTextField? If it is, couldn't you just do:

Code:
if ([totalXpField.stringValue isEqualToString:@"Blahblahblah"]) {
        NSLog(@"Yes");
    }
    else{
        NSLog(@"No");
        NSLog(@"it says:%@",totalXpField.text);
    }

Or something similar
 
Last edited:
Is totalXPField an NSTextField? If it is, couldn't you just do:

Code:
if ([totalXpField.text isEqualToString:@"Blahblahblah"]) {
        NSLog(@"Yes");
    }
    else{
        NSLog(@"No");
        NSLog(@"it says:%@",totalXpField.text);
    }

Or something similar

It would be totalXpField.stringValue, not totalXpField.text.
 
I understand. So the == 'Equal to' operator is only to be used to compare numeric values.

When you're using '==' to compare objects (NSStrings are objects of course), it's comparing whether the pointers are pointing to the same place in memory. In this situation, it's possible to have identical values each stored in 2 separate memory locations and the '==' operator will return false.
 
But wait. If I have int x,y; and say x= 5; and y = 5; then compare then 'x == y'. It will be comparing 2 variables at to different memory addresses, so it should return a false. So when I use == with objects, it is using the pointers, But when I use the == to compare integers it is comparing that actual integers at different memory addresses, right?

-Lars
 
You're overthinking it.

The address of the variable isn't being compared. The value of the variable is.

In C (or Obj-C), &x is the address of a variable x. The plain unadorned x is the value of the variable.

If the type of x is a pointer, e.g.:
Code:
NSString * x;
then the value of x is a pointer.

If the type of x is an int (or any non-pointer type), e.g.:
Code:
int x;
then the value of x is an int (or the declared type).

In either case, &x is the address of the variable x, and is not used in comparisons unless you actually state &x.
 
Last edited:
But wait. If I have int x,y; and say x= 5; and y = 5; then compare then 'x == y'. It will be comparing 2 variables at to different memory addresses, so it should return a false. So when I use == with objects, it is using the pointers, But when I use the == to compare integers it is comparing that actual integers at different memory addresses, right?

-Lars

You are always comparing the value stored in the variable. But when dealing with objects, the value stored in the variable is a pointer to an object. The object itself is not stored in the variable. That's why the * is needed when declaring them. * means 'pointer'.

Read:

NSArray *myArray;

as "An NSArray pointer called myArray"


This can also be done with int's, and there are good reasons at times to have a pointer to an int. If you have a begining C book go through the chapter on pointers. It will probably show some pointer examples using ints and chars.
 
Just to make the point crystal clear (because this is an important concept to understand fully), if you've got a pointer to an NSString, x:
Code:
NSString *x = @"someString";
The value of x will be a memory address like 0x7fff7ebd1858, not the actual string. So if you have somewhere else in your code:
Code:
NSString *y = @"someString";
The value of y will be a different memory address like 0x7fffdeadbeef,
and when you do a x == y comparison, it's saying that:

0x7fff7ebd1858 != 0x7fffdeadbeef

which is why it returns false.

It's also why when you assign the value of object1 to object2, it's literally just copying over the address of object1's memory into object2. An important corollary to this is that operations are very efficient because much of Objective-C is just moving pointer values around, so it boils down to very simple operations for the processors.
 
Last edited:
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.