Sure, but the consumer of the framework is still an Objective-C application or framework, which is going to be using NSStrings for everything else already and presumably up to the boundary with this framework. Why make the consumer do the conversion? If the method is going to be called “a lot”, the framework can cache UTF8 representations, just like the consumer was going to have to do anyway.
Daniel On Mar 3, 2014, at 5:18 PM, Jens Alfke <j...@mooseyard.com> wrote: > > On Mar 3, 2014, at 7:19 AM, Daniel DeCovnick <danhd...@mac.com> wrote: > >> Are these selectors bound to library functions that must take char *’s and >> you can’t afford the overhead of a second method dispatch or function call > > The OP is working with Mono, a C# runtime, so I’m sure the glue to it takes C > strings. > > The overhead of using NSString would be greater than just a method dispatch. > Converting an NSString to a UTF-8 C string will often require allocating > memory, depending on the internal representation the NSString is using and > whether it contains non-ASCII characters. (NSStrings are internally stored as > either UTF-16 or MacRoman, not UTF-8.) > > —Jens _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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 arch...@mail-archive.com
