Article:		Strings in Cocoa: Part I
Subject:		Comparing strings
Date:		2001-07-03 14:38:00
From:		wcray
Response to: Comparing strings
> Actually, comparing string1 and string2 > with == didn't work > when I compiled Mike's code fragment as > a standard tool. > This is surprising because... Actually not unexpected. string1 and string2 were declared as unbounded char arrays, which gcc assumes aren't constant strings (while type char *s with initializers are assumed to be constant). I believe the logic is that char foo[] = "yabba dabba"; declares foo to be a character array, and then the initializer puts data into it, while char *foo2 = "yabba dabba"; declares foo2 to be a pointer, and the initializer points it to a string containing "yabba dabba" that already exists in the memory space.

Showing messages 1 through 4 of 4.

• Comparing strings
  2001-07-03 16:44:43  canyonrat [View]
  
  
  >Actually not unexpected. string1 and string2
  >were declared as unbounded char arrays, which
  >gcc assumes aren't constant strings (while
  >type char *s with initializers are assumed
  >to be constant).
  
  That's really good to know. Thanks!
• Comparing strings
  2001-07-04 18:36:41  bigboytoddy [View]
  
  
  Okay, so when are each used, and why? I appreciate the ANSI C lessons here, as it seems
  it is a ANSI issue, which brings me to ask why (again)? Where would this differentiation make a slack ass like me what to know the difference...?
  
  Thanks
  
  \t
  
• Comparing strings
  2001-07-04 23:33:56  canyonrat [View]
  
  
  What this is telling me is that you almost always want char* s rather than char[] s. The first form gives gcc permission to be smart about checking whether you have already used the string and, if you have, just reusing it rather than saving a mew copy and bloating your code.
  
  For example consider:
  char* aString = "hello";
  and later
  char* bString = "hello"
  
  the compiler has permission to notice that aString == bString and just reuse aString.
  
  The second form says that you might want to change bString later and you don't want that to effect aString so they must be stored separately. But you won't need this second form in ObjC because you can use NSMutableString instead.
  
  Of course the best rule for C style strings is don't use them at all. They are just too complicated and error prone.

• Comparing strings
  2001-07-03 15:53:58  Michael Beam | [View]
  
  
  Thats pretty much what i came across when i was playing around with this the other day. I didn't understand the logic, but now i do. This is great stuff!--Learning these language level types of details that is.