Re: NSString format specifiers (was: Is Concatenation that complex?)
Re: NSString format specifiers (was: Is Concatenation that complex?)
- Subject: Re: NSString format specifiers (was: Is Concatenation that complex?)
- From: Gwynne <email@hidden>
- Date: Tue, 27 Apr 2004 22:00:20 -0400
On Apr 27, 2004, at 8:59 PM, Allan Odgaard wrote:
[...] The only difference between printf() specifiers and
NSString/CFString specifiers is that the latter add %C
(Unicode/wchar_t version of %c), %S (Unicode/wchar_t version of %s),
No, these things are also supported for the stdlib, where S is short
for ls (wchar_t*) and C is short for lc (wchar_t). The documentation
says:
For each wide character in the string, the
(potentially multi-byte) sequence representing
the wide character is written, including any
shift sequences [...]
But I don't think it actually works for non 8 bit characters.
I believe those were added to stdio printf() in Panther, along with
several other specifiers that were missing until then.
and %@ (any Cocoa or CoreFoundation object, as the result of [object
description] or CFCopyDescription(object).) Someone correct me if I
forgot or misrepresented any :).
CFString/NSString also supports reordering of arguments, e.g.:
NSLog(@"%2$@ %1$@", @"world", @"hello");
Which will print "hello world". This is very useful for localizing.
That's supported by stdlib as well. You can do some pretty darn neat
things with stuff like %*.*f for conveniently passing the number of
digits to display and round to for floating-point numbers. (* means
"read the value from the next argument in the arglist.)
But it fails to support the 'z' modifier (used for size_t). Maybe if
they would document their supported format specifiers/placeholders, I
would know wether or not this is a bug ;)
The reason for this is that CFString and NSString reimplement the
printf() format specifier logic on their own, so if Apple doesn't keep
the implementation of CFStringCreateWithFormatAndArguments() in sync
with that of v[fs]printf(), we end up with discrepancies in the feature
set. Interpreting new format specifiers is no simple thing, mainly due
to the complexity of argument reordering and the inability to safely
manipulate va_lists. It's not simply a matter of replacing all
occurances of "%@" with the result of [obj description], because you
have to parse every specifier in the string out to know which argument
to access, and at that point it's easier to just implement the logic
(including being able to write into your own buffer for data) yourself
rather than trying to call through to vsprintf().
-- Gwynne, key to the Code that runs us all
Formerly known as Sailor Quasar.
Email: email@hidden
Web:
http://musicimage.plasticchicken.com/
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.