|
From: | Luboš Doležel |
Subject: | Re: Implementing NSString getBytes |
Date: | Sun, 09 Jun 2013 21:34:20 +0200 |
User-agent: | Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 |
On 06/09/2013 04:30 PM, Fred Kiefer wrote:
I like the idea of adding this functionality. You actual implementation wont do as you already noticed. We also cannot use iconv() unconditionally. I remember back in time when I first added a call to iconv() to GNUstep we also had to introduce the configure checks for it. And of course provide a fall back implementation for that rare case where it isn't available. You should also have a second look at GSFromUnicode() to notice it is trying a much better job at providing a lossy conversion.
Oh yes, I saw that. It makes me wonder, though, why bother supporting the non-iconv case at all, since that may cause trouble to apps that expect conversion to work. But hey, it's already done.
You already pointed out the difference that you need to the current implementation of GSFromUnicode(). You don't want your function to allocate extra memory, you need it to return the index up to which it was able to convert characters and you need a different return code that states whether any characters where converted. Although the last could possibly be determined by checking the returned index. Now this sounds like a strict extension of GSFromUnicode() and I think that in the long run these two functions should share their implementation code. But we also need to make sure that GSFromUnicode() is rock solid and fast, maybe we first keep them separate. Maybe it is best if you first write your new function by extracting all the code from GSFromUnicode() that doesn't handle memory management and add the different return values there. Next we could think about rewriting GSFromUnicode() on top of that. Adding the memory management and using some pointer arithmetic. And then we test whether this is fast enough.
I was expecting you to say something like that :-)I don't like the current GSFromUnicode() implementation - probably because of the GROW() macro and the non-iconv case mess.
It could be more readable to write a minimal iconv implementation for builds without iconv, GSFromUnicode() could then only have a single branch of code.
-- Luboš Doležel
[Prev in Thread] | Current Thread | [Next in Thread] |