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

zcarter

macrumors member
Original poster
Apr 21, 2007
46
0
Hey guys..Im learning SQLite and I came across this feature.

self.author = (str) ? [NSString stringWithUTF8String:str] : @"";

I understand its taking the current string from the SQL and putting it into the defined string self.author using UTF8String formatting (becauses its stored in the SQL that way)...

So..what does the '?' in that have to do with it?

Thanks!

- Zac
 

lee1210

macrumors 68040
Jan 10, 2005
3,182
3
Dallas, TX
It's a ternary if. It evaluates the operand on the left of the ? operator. If it evaluates to true, the expression will evaluate to the value of the operand on the left of the :. If it evaluates to false, the expression will evaluate to the value on the right of the :. In this case, if str is not null, the string from the utf string pointed to by str will be returned. Otherwise an empty string will be returned.
 

zcarter

macrumors member
Original poster
Apr 21, 2007
46
0
Thanks.

Thank you sir. Man, I should have known better =-p I learned that in CS140 lol
 

lee1210

macrumors 68040
Jan 10, 2005
3,182
3
Dallas, TX
No problem. I'd probably say this is by far the lesser used alternative. It is more concise than:
Code:
if(str != NULL) { //For god's sake, be explicit about it. True/false, not 0/non-0
  self.author = [NSString stringWithUTF8String:str];
} else {
  self.author = @"";
}

I wouldn't say either is more clear. Some people thing the ternary if is awful, and try to forbid it in their project/organization/etc. Some think it's the right way to do things like this. It's a matter of taste and style. The real risk is that upon immediate inspection most will instantly know what's going on with the if/else, and some might take pause with the ternary if.
 

pilotError

macrumors 68020
Apr 12, 2006
2,237
4
Long Island
I wouldn't say either is more clear. Some people thing the ternary if is awful, and try to forbid it in their project/organization/etc. Some think it's the right way to do things like this. It's a matter of taste and style. The real risk is that upon immediate inspection most will instantly know what's going on with the if/else, and some might take pause with the ternary if.

I call it job security. You would be shocked how many people don't know how to use ternary operators.
 

gnasher729

Suspended
Nov 25, 2005
17,980
5,566
No problem. I'd probably say this is by far the lesser used alternative. It is more concise than:
Code:
if(str != NULL) { //For god's sake, be explicit about it. True/false, not 0/non-0
  self.author = [NSString stringWithUTF8String:str];
} else {
  self.author = @"";
}

I wouldn't say either is more clear. Some people thing the ternary if is awful, and try to forbid it in their project/organization/etc. Some think it's the right way to do things like this. It's a matter of taste and style. The real risk is that upon immediate inspection most will instantly know what's going on with the if/else, and some might take pause with the ternary if.

When I started my career, my then boss, who also did a bit of programming, complained that my style was too terse. He claimed that one screenful of his code was much easier to understand than one screenful of my code. I said yes, that was true, but one screenful of my code did more than six screenfuls of his code, and that one screenful of my code was much easier to understand than six screens of his code. If you are setting not only "author", but a dozen other things as well, then a dozen if/else statements are harder to read and check for mistakes than a dozen ternary operators.

I agree with the comparison "str != NULL" though; Java got that right by only allowing boolean expressions in an if statement (or ternary operator).

I minor point: If "author" is not a class member but a property, then the if/else can lead to a lot of duplicated object code.
 

lee1210

macrumors 68040
Jan 10, 2005
3,182
3
Dallas, TX
When I started my career, my then boss, who also did a bit of programming, complained that my style was too terse. He claimed that one screenful of his code was much easier to understand than one screenful of my code. I said yes, that was true, but one screenful of my code did more than six screenfuls of his code, and that one screenful of my code was much easier to understand than six screens of his code. If you are setting not only "author", but a dozen other things as well, then a dozen if/else statements are harder to read and check for mistakes than a dozen ternary operators.

I agree with the comparison "str != NULL" though; Java got that right by only allowing boolean expressions in an if statement (or ternary operator).

I minor point: If "author" is not a class member but a property, then the if/else can lead to a lot of duplicated object code.

People can program poorly with any (or without any, really) style. There's a definite trade-off between being terse and being more explicit. Hopefully if there are fewer lines there's a smaller chance of making an error, and when done properly it should be as readable as more explicit code. With more explicit code it's more likely that "anyone" will be able to read it, but there's more room for error, and if "anyone" is going through your code they may be more likely to introduce bugs no matter what style you use.

The only time brevity is truly costly to understanding is when a programmer tries to use obscure or confusing syntax to save a line or two of code. Just because you can put a whole C program on one line doesn't mean you should.
 

kainjow

Moderator emeritus
Jun 15, 2000
7,958
7
Sometimes I use this, but it depends on the situation. However I almost always use parentheses and check for nil/NULL explicitly since I think it's easier to read. For example:

Code:
self.author = (str != NULL ? [NSString stringWithUTF8String:str] : @"");
 

SqueegyX

macrumors regular
Mar 24, 2008
108
1
I agree with the comparison "str != NULL" though; Java got that right by only allowing boolean expressions in an if statement (or ternary operator).

Ruby does it best, IMHO. The only objects treated as false are "false" and "nil", every other value is true. It keeps code lean when checking variables have been initialized. You can still do "some_var.nil?" or "some_vale == false" if you want to get explicit about it.
 
Register on MacRumors! This sidebar will go away, and you'll see fewer ads.