So... the lowly NSString. Where shall I begin? Maybe with the simple idea that whatever text processing I needed to do, NSString (and supporting objects) always seems to provide a means to do it (sometimes thanks to methods added after-the-fact to the NSString object). And also that getting a C string is almost never needed unless interacting with a C library (the standard C library shouldn't be needed).
NSString is very similar (for historical reasons) to Java's String object. Both can not be changed after being created, changes are rather require the creation of a new object (In such cases - NSAutoReleasePool is your friend if you find yourself doing innumerable string manipulations):
NSAutoreleasePool *p
= [[NSAutoreleasePool alloc] init];
//Do plenty of string operations using
//[NSString string*] methods.
[p release];
= [[NSAutoreleasePool alloc] init];
//Do plenty of string operations using
//[NSString string*] methods.
[p release];
That's the beginning. Ok; time for some fun! Let's say there are plenty of string constants that need to be internationalized? The simplest solution is to write the following for strings:
NSString *s = NSLocalizedString(@"Hello", @"Greeting String");
If you've set up your translation files correctly (get them using genstrings), then "Hello" is the word to get in the current language, and "Greeting String" is a hint to the translator.
Can we do more with NSString? Of course! splitting, loading a string from a file, and all sorts of other operations can be done.
I'll just note a few objects that can be useful rather than give a complete tutorial on them (the Apple docs are very good).
NSCharacterSet defines a set of unicode characters. This object provides a quick way to get all white-space, all punctuation, and even all newline character sets. Very useful when parsing files or breaking up strings.
NSScanner provides a nice way to scan any arbitrary file. It is much more flexible than the standard C/C++ file operations in that it returns the data (String, float, etc. - even delimited to an NSCharacterSet) and a boolean specifying whether the data was obtained. This makes parsing more complex files... easier. (I don't doubt that it can be done in C/C++ - just that assuming the structure might vary rather than be fixed is a nice one. eg. optional floating-point number would be read as 0 in C++ if memory serves.)
NSXMLParser is nice - but I'm not really a fan of XML. Let's say that there are neater ways to represent data than XML. XML is nice for being standard - but the tags are just too much for me. But it's there and works great!
NSString can also do everything that the standard C library does. Just that I don't worry about memory buffer sizes. I'm not familiar enough with the C++ String class to comment on it.
And for speed, CFString allows quick access to the underlying data:
//Direct cast -
//toll-free-bridge as Apple calls it.
CFStringRef r = (CFStringRef)@"NSString";
CFStringLineBuffer b; //... inline buffer used to iterate...
So yes - this has devolved into a rant. It's conclusion: look at what NSString does. It does a lot more than what you think. Especially thanks to categories that allow for any programmer to give NSString more functionality (that's how it can render text to views - and how external libraries could use it - to render strings to textures, etc.).
//toll-free-bridge as Apple calls it.
CFStringRef r = (CFStringRef)@"NSString";
CFStringLineBuffer b; //... inline buffer used to iterate...
Unfortunately, this is true of most modern APIs - and for all objects. That is; the objects can do so much. It's no longer a question of knowing how to do something - but knowing the magic keyword that will return the proper function in a search result.
OK, a mini-rant,
<rant>
Programmers now work at such a high-level. And that high-level will allow us to keep on coding as normal while everything transparently becomes parallel (something I've been thinking a lot about recently - the challenge may appear great; but in retrospect abstraction makes it easier. As a hint - we parallelize like the CPU does with instructions. Branches are our undoing - yes I'm captain obvious. I think QT Concurrent is the closest to what I'm thinking - but there is a way to provide a sequential API with parallel underpinnings. It already in the form of OpenGL. The real trick - which I'm almost done tinkering with - is how to get modules that don't know about each other communicating in a relevant way in parallel.).
</rant>
