Article:		Strings in Cocoa: Part I
Subject:		Comparing strings
Date:		2001-06-30 13:15:07
From:		nriley
char string1[] = "Yo"; char string2[] = "Yo"; if ( string1 == string2 ) { // do the following code } And the conditional would evaluate to "true", executing the code within the braces of the if statement. Er, yes, but only if the compiler decides to share the area of memory used by the string constants. The equivalent of compare: for C strings is strcmp. I'm enjoying your article series - keep it up! --Nicholas

Showing messages 1 through 8 of 8.

• Comparing strings
  2001-07-04 18:34:01  bigboytoddy [View]
  
  
  OK, when would a compiler (GCC or others) not decide to share constant memory locations? Is there a directive to GCC to make every single constant a unique instance. I guess there would be, share with me where this would be useful, in DO or other networking usages? I'm very interested. Thanks.
  
  \t
  

• Comparing strings
  2001-07-02 07:41:35  canyonrat [View]
  
  
  Actually, comparing string1 and string2 with == didn't work when I compiled Mike's code fragment as a standard tool. This is surprising because both my memory and Help Viewer agree that gcc pools strings by default.
  
  Wouldn't operator overloading be nice in ObjC? Comparing NSString with == should work.
• Comparing strings
  2001-07-03 14:38:00  wcray [View]
  
  
  > 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.
  
• 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.

• Comparing strings
  2001-06-30 22:07:07  Michael Beam | [View]
  
  
  I see...thanks for the heads up, and i'm glad your enjoying the articles!