by Michael S. Kaplan, published on 2011/12/08 07:01 -05:00, original URI: http://blogs.msdn.com/b/michkap/archive/2011/12/08/10245601.aspx
In a comment on a blog I wrote nearly 7 years ago (How do sort keys work?), Alexander Savin asked another bunch of questions:
If I need to generate a sort key for the string I have to call LCMapString twice:
bufferSize = LCMapStringW(..., 0);
Is there a performance flaw in this approach? Doesn't this imply that LCMapString does a double work? Does LCMapString need to scan an input string to determine the sort key size?
If it does, I would very much prefer having an ability to pass, in a single call, the pre-allocated buffer size and having LCMapString return the required buffer size if the input one appears to be not large enough.
What about the following approach (if I don't need a sort key itself but only its hash code)?
...Allocate 512 bytes on stack...
sortKeySize = LCMapStringW(..., 512);
if (sortKeySize == 0)
sortKeySize = LCMapStringW(..., 0);
It does a triple work in the worst case but should work faster in most cases. Shouldn't it?
Also, having to estimate the worst sort key size, considering an input string has the length of N, is it true that its sort key is no longer than (2*N + 1)*4?
And if IgnoreCase is specified, for example, will the [all Case weights] section be empty?
Michael, it would be very helpful if you could clarify all this? Thanks.
Giving answers to each question consecutively:
Hey, that was easy. :-)
go to newer or older post, or back to index or month or day