| 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...
|
||
Showing messages 1 through 4 of 4.
-
Comparing strings
2001-07-03 16:44:43 canyonrat [View]
-
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.



>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!