-1

Can +[NSArray arrayWithObjects] and the newer, literal syntax produce different results?

  1. Is there any chance that the newer syntax produces different results? Example case is 3 literal strings:

    return [NSArray arrayWithObjects:@"one", @"two", @"three", nil];

    versus

    return @[@"one", @"two", @"three"];

  2. Is it possible to see the macro code for the literal syntax, and if so, where? (please correct me if this question makes no sense)
Dan Rosenstark
  • 68,471
  • 58
  • 283
  • 421
  • I really doubt thats it, any chance you can describe the bug? Maybe we can help narrow it down. – Joel Bell Dec 03 '14 at 17:23
  • 3
    Always suspect that _you_ are doing something wrong. You will not be a successful programmer if you constantly suspect the compiler, the framework, and so forth. They know more than you do. Use the debugger, use logging, track down the problem. You have not said what it is, but I guarantee that the fault is _you_. – matt Dec 03 '14 at 17:26
  • No you can't see the "macro code". It isn't a macro. It is language syntax. There is nothing to "see". – matt Dec 03 '14 at 17:29
  • I don't see where he's “suspecting the compiler” of anything. He's asking if there can be a difference in results between two techniques, which is perfectly valid to ask, and in this case, there **is** a pretty important difference. – rob mayoff Dec 03 '14 at 17:32
  • Thanks @matt, this is a hypothesis. Both successful and less successful programmers can use them! http://en.wikipedia.org/wiki/Hypothesis – Dan Rosenstark Dec 03 '14 at 17:40

1 Answers1

6
  1. Yes, there's a chance of a difference. Consider:

    NSString *v = nil;
    NSArray *a1 = @[ @"bob", v, @"fred" ];
    NSArray *a2 = [NSArray arrayWithObjects: @"bob", v, @"fred", nil];
    

    Then the attempt to construct a1 raises an exception at runtime and your program crashes, because you've tried to include nil in an NSArray. The attempt to construct a2 creates an array of one item, @"bob", because the nil in v terminates the argument list.

  2. There is no “macro code” for the literal syntax. It's part of the compiler source code, which is C++. Look at method Sema::BuildObjCArrayLiteral in SemaExprObjC.cpp.

rob mayoff
  • 375,296
  • 67
  • 796
  • 848
  • Thanks, this is an interesting case. So if all of the strings themselves are literals, this difference is not possible, right? – Dan Rosenstark Dec 03 '14 at 17:37
  • 2
    Right. Although it would be helpful if you posted your exact code. – Zev Eisenberg Dec 03 '14 at 17:44
  • @ZevEisenberg TBH the code relevant for this question is exactly replacing the old syntax for the newer syntax with a bunch of string literals. The bug that I'm trying to fix is weird and intermittent and exists somewhere in a huge codebase for which I'm the author (MIDI Designer). Since the bug has only manifested in the Beta version and not production, I'm spelunking with git to figure out what's up. I just wanted to check if I could rule out this hypothesis, which I can now. – Dan Rosenstark Dec 03 '14 at 17:49
  • Xcode will perform the syntax replacement for you, and it won't make any mistakes when it does so. Choose Edit > Refactor > Convert to Modern Objective-C Syntax. – matt Dec 03 '14 at 18:04
  • Oh, one more little thing: the Analyzer will catch any cases of the first mistake (`a1`). It won't catch any cases of the second mistake because it's not a mistake. This, indeed, is a reason for preferring the modern syntax. – matt Dec 03 '14 at 18:09
  • Thanks everybody for the help. Back to the diff... – Dan Rosenstark Dec 03 '14 at 18:25