Le 31 mars 2012 à 18:20, Andreas Grosam a écrit :

> Thank you all for your answers and suggestions.
> 
> My use case is to create CFStrings from Unicode - which in the majority of 
> cases are "short" strings - say, less than 100 characters. In this case, I 
> create an immutable CFString directly in one go.
> 
> Less frequently in the typical use case of the application, I have to deal 
> with larger strings, say base64 encoded images, or something like this. Yet, 
> I need to create a CFString. Since the content will be received over the net, 
> I naturally get content in chunks anyway (namely NSData objects received from 
> a connection). So, in order to avoid a large temporary buffer which holds the 
> complete string, I use a smaller buffer, e.g. 4 KByte and then append this 
> small buffer to the resulting CFString, until it is complete.
> 

If this is to store base64, I would rather use NSData instead of NSString, and 
even better, I would use a staged base64 decoder that let me decode the data 
when they arrive, and store the result in NSMutableData 

> As Greg suggested, I'll try my solution first and test whether it will work 
> efficiently:
> 
> CFStringRef tmp = CFStringCreateWithBytesNoCopy(kCFAllocatorDefault, bytes, 
> numBytes, encoding, NO, kCFAllocatorNull);
> CFStringAppend(myMutableString, tmp);
> CFRelease(tmp);
> 
> 
> Nonetheless, if there is a chance that a possible implementation
> 
> void CFStringAppendBytes (
> CFMutableStringRef theString,
> const void* bytes,
> CFIndex numBytes,
> CFStringEncoding encoding
> );
> 
> 
> will be faster, or uses less memory, I'll also file an enhancement request.
> 
> 
> 
> Thanks All!
> 
> Regards
> Andreas
> 
> 
> 
> On Mar 28, 2012, at 9:24 PM, Greg Parker wrote:
> 
>> On Mar 28, 2012, at 11:00 AM, Charles Srstka <[email protected]> 
>> wrote:
>>> Unicode NULL is the least of your problems. In UTF16, each character in the 
>>> normal ASCII range is going to contain a zero as one of its two bytes 
>>> (which one, of course, depending on whether the encoding is big- or 
>>> little-endian). CFStringAppendCString(), along with the other functions 
>>> that take C strings, stops at the first zero byte it hits, which means that 
>>> unless your entire file is in a non-Western script, it’s going to get cut 
>>> short.
>>> 
>>> CFStringAppendCString() is not what you want if you might be using UTF16.
>> 
>> That's right. The first thing CFStringAppendCString() does is call strlen().
>> 
>> CoreFoundation does have a function internally that would do what you want. 
>> You could file a bug report asking for a new API to match. However, it 
>> requires almost as much work as using a temporary CFString object anyway, 
>> except in some ASCII and UTF-16 cases. I would not expect your 
>> CFStringCreateWithBytesNoCopy() solution to be much slower unless you're 
>> performing a large number of short appends with one of CFString's preferred 
>> encodings.
>> 
>> 
>> -- 
>> Greg Parker      [email protected]     Runtime Wrangler
> 
> _______________________________________________
> 
> Cocoa-dev mailing list ([email protected])
> 
> Please do not post admin requests or moderator comments to the list.
> Contact the moderators at cocoa-dev-admins(at)lists.apple.com
> 
> Help/Unsubscribe/Update your Subscription:
> https://lists.apple.com/mailman/options/cocoa-dev/devlists%40shadowlab.org
> 
> This email sent to [email protected]

-- Jean-Daniel





_______________________________________________

Cocoa-dev mailing list ([email protected])

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to [email protected]

Reply via email to